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Der Presentation Manager ist ein echtes Multitasking-System, 
gleichzeitig ist er jedoch auch meldungsgesteuert. Das kann bei 
zeitaufwendigen Routinen dazu führen, daß Anwendungen sich 
gegenseitig blockieren, wenn sie nicht sauber programmiert sind. 
Charles Petzold zeigt, worauf Sie achten müssen. 


In einer mehrteiligen Serie wird Michael Tischer ab dieser Aus- 
gabe die Implementierung einer SAA-kompatiblen Benutzerober- 
fläche beschreiben. Diesmal geht es um die Low-Level-Routinen 
für die Bildschirmansteuerung und die Fensterverwaltung. 


Komplizierte Deklarationen werden oft sogar von guten C- 
Programmierern nicht vollständig verstanden. Das Verständnis 
von Deklarationen ist jedoch die Basis für das Verständnis von C. 


Paul Yao. beschreibt, wie Expanded Memory arbeitet, wie 
Windows Expanded Memory verwendet und wie Expanded 
Memory Ihre Windows-Programme beeinflußt. 


In fast jedem Programm werden Routinen für Zeichenvergleiche 
und Zeichenklassifizierung benötigt. Wir bringen allgemeingültige 
tabellengesteuerte Assemblerversionen. 


Microsoft bietet mit der Version 3.0 des optimierenden COBOL- 
Compilers ein leistungsfähiges Werkzeug zur Entwicklung und 
Wartung von Mainframe-Anwendungen in der PC-Umgebung an. 


Im November 1988 veranstaltete Microsoft in Frankfurt ein Sym- 
posium für Fachhändler, Distributoren, Großkunden und Soft- 
wareentwickler. Dabei wurde Rückschauf auf 1988 gehalten, aber 
vor allem Hard- und Softwareperspektiven für 1989 aufgezeigt. 


Neue Produkte, Aktuelles 

Die Termine des Microsoft-Instituts 

Sysgen-Laufwerke, Buch-Disk 

Das System Journal versucht seine Bücherflut zu bewältigen (II) 
»Profi-Tools« für die Stringbehandlung in C 
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MS OS/2 Presentation Manager 


Der Einsatz mehrerer Thr nter dem Pr 


ion r: 


Multi-Thread-Anwendungen unter MS OS/2 1.1 


Microsoft Windows ist eine Multitasking-Umge- 
bung - allerdings nicht ganz. Wie die meisten 
Windows-Programmierer wissen, ist Windows 
eine nicht preemptive Multitasking-Umgebung. 
Es führt kein preemptives Time-Slicing durch, 
das normalerweise mit einem Multitasking- 
System verbunden wird. Statt dessen verläßt 
sich Windows beim Multitasking auf das Vor- 
handensein von Meldungen (wobei es sich oft 
um Tastatur- und Mauseingaben handelt) in der 
Meldungs-Queue des Programms. 


Wenn ein Windows-Programm die Funktion GetMessage 
aufruft, um die nächste Meldung aus der Meldungsqueue zu 
lesen, und diese leer ist, unterbricht Windows das Pro- 
gramm. Windows schaltet dann auf ein anderes Programm 
um, dessen Meldungsqueue nicht leer ist. Dies bewirkt, daß 
das andere Programm von seinem eigenen GetMessage- 
Aufruf zurückkehrt um die Meldung zu bearbeiten. Zu 
einem Zeitpunkt läuft immer nur ein Windows-Programm. 
Die anderen werden in der GetMessage-Funktion zeitwei- 
lig angehalten. 

Windows-Programmierer sind sich der Probleme, die 
sich aus dieser Art des Multitasking ergeben, wohl bewußt. 
Wenn ein Windows-Programm zur Bearbeitung einer Mel- 
dung viel Zeit benötigt, werden andere Programme unter 
Windows für diese Zeit effektiv angehalten. Windows-Pro- 
grammierer müssen bei der Bearbeitung langwieriger Auf- 
gaben besondere Techniken verwenden (die ich später noch 
erläutern werde), um zu verhindern, daß ein Programm den 
Rest des Systems anhält. 

Der MS OS/2 Presentation Manager ist, ähnlich wie 
Microsoft Windows, eine Fensterumgebung mit einer mel- 
dungsorientierten Architektur. Doch anders als Windows 
läuft der Presentation Manager unter einem prioritätsge- 
steuerten, preemptiven Multitasking-Betriebssystem. 

Auf den ersten Blick könnte man glauben, daß durch 
das preemptive Multitasking des OS/2-Systems die Pro- 
bleme, die durch die nicht preemptive Natur von Windows 
entstehen, beseitigt wären. Sie könnten den Schluß ziehen, 
daß Presentation Manager-Programme mit der Verarbei- 
tung einer Meldung beschäftigt sein dürfen, so lange sie 
wollen. Doch das ist nicht so. Die Probleme, die auftreten, 
wenn zeitaufwendige Arbeiten unter Windows erledigt wer- 
den, ergeben sich mehr aus der meldundgsorientierten 
Architektur als aus dem nicht preemptiven Multitasking. In 
diesem Sinne verhält sich der Presentation Manager wie 
Windows. 

Der wirkliche Unterschied liegt darin, daß der Presen- 
tation Manager mehr und bessere Lösungen für die Pro- 
bleme von zeitaufwendigen Aufgaben bietet. Das soll in die- 
sem Artikel genauer untersucht werden. 
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BIGJOB.H: Header-Datei 
1D_RESOURCE 1 


IDM REES 1 
IDM ACTION 2 


#ifndef RC_INVOKED /* This stuff not needed for .RC file */ 
#define STATUS_READY ß 

#define STATUS_WORKING 1 

#define STATUS_DONE 2 

ULONG EXPENTRY ClientkndProc (HWND, USHORT, ULONG, ULONG) ; 
HAB hab ; 

double Savage (double A) 


ZERR tan (atan (exp (log (sqrt (A * A))))) + 1.8; 


VOID CheckMenultem (HWND hwnd, SHORT iMenultem, BOOL bCheck) 


HWND hundParent = WinQueryWindow (hund, QW_PARENT, FALSE); 
HWND hundMenu = WinkindowFromID (hwndParent, FID _MENU) ; 


WinSendMsg (hwndMenu, MM_SETITEMATTR, 
MAREULONG (1Menultem, TRUE), 
MAKEULONG (MIA _( 


CHECKED, 
j bCheck ? MIA CHECKED : 8)) ; 


ir (HWND hwnd, SHORT iMenulten, BOOL bEnable) 


HWND hwndParent = WinQueryWindow (hund, QW_PARENT, FALSE); 
HWND hwndMenu = WinkindowFromID (hundParent, FID _MENU); 


WinSendMsg (hwndMenu, MM SETITEMATTR, 
MAREULONG (iMenultenm, TRUE), 
MAKEULONG (MIA_DISABLED, 
' bEnable ? 8 : MIA_DISABLED)) ; 


PaintWindow (HWND hund, SHORT iStatus, SHORT iRep, 
LONG 1Time) 


{ 
static CHAR *szMessage [3] = { "Ready", 


"Working ...”, 
"sd repetitions in Xld nsec.” } ; 

CHAR szBuffer [68] ; 

HPS hps ; 

WRECT 

hps = WinBeginPaint (hund, NULL, NULL) ; 

GpiErase (hps) ; 

WinQuerykindowRect (hund, &urc) ; 

sprintf (szBuffer, szMessage [iStatus], iRep, 1Time) ; 


WinDrawText (hps, -1, szBuffer, &urc, 
DT_CENTER | DT_VCENTER) ; 
TERN (hps) ; 


Zendif 


Listing 1 


MS OS/2 Presentation Manager 


BIGJOB.RC: Ressourcen-Datei 


#include <os2.h> 
#include "bigjob.h” 


MENU ID_RESOURCE 
SUBEN) "Repetitions”, IDM_REPS 


MIA_CHECKED 


MENUITEM " 10", IDM_18, 
DM 188 


MENUITEM ” 188”, IDM_ 
MENUITEM " 1088”, IDM_ 1888 
MENUITEM " 19808”, IDM_ 18008 


} 
erh "Action", IDM_ACTION 


MENUITEM ""Start”, IDM_START 
raue "“Abort”, IDM_ABORT, MIA_DISABLED 


Listing 1 (Ende) 


Das Problem der »großen Aufgabe« 


Presentation Manager-Programme können Tastatur- und 
Mauseingaben gewöhnlich sehr schnell bearbeiten. Bei- 
spielsweise braucht in einer Textverarbeitung ein einge- 
gebenes Zeichen nur in den Text eingefügt und auf dem 
Bildschirm angezeigt werden. Doch viele Programme müs- 
sen auch Befehle ausführen, die zu einer längeren Verar- 
beitung führen. Mein Ausdruck für diese zeitaufwendigen 
Aufgaben lautet »große Aufgabe«. 

In einer Presentation Manager-Tabellenkalkulation ist 
eine große Aufgabe zum Beispiel die Neuberechnung oder 
die Ausführung eines langen Makros. In einem Datenbank- 
programm ist die Sortierung oder die Indizierung eine 
große Aufgabe. In einem Textverarbeitungsprogramm ist es 
der Umbruch oder die Rechtschreibprüfung. In einem 
CAD-Programm ist es das Neuzeichnen des Bildschirms. In 
einem Kommunikationsprogramm das Lesen der seriellen 
Schnittstelle, wenn ein Zeichen nicht sofort verfügbar ist. In 
fast jedem Presentation Manager-Programm ist der Druck 
eine große Aufgabe. 

Alles was länger dauert als 1/10 Sekunde, ist eine große 
Aufgabe. Diese Angabe stützt sich auf die Empfehlung in 
der Presentation Manager-Dokumentation, daß Programme 
zur Bearbeitung einer Meldung nicht mehr als 1/10 Sekun- 
de benötigen sollten. Auch wenn es sich dabei nur um einen 
Richtwert handelt und nicht um eine unumstößliche Regel, 
nenne ich das die »1/10-Sekunden-Regel«. 

Zur genaueren Untersuchung der Probleme bei großen 
Aufgaben wollen wir ein Presentation Manager-Programm 
schreiben, daß eine große Aufgabe erledigt, und zwar eine 
Berechnung, die Savage-Benchmark genannt wird, der oft 
für den Test der Geschwindigkeit von Fließkomma-Arith- 
metik verwendet wird. Das Programm erlaubt die Wieder- 
holung der Savage-Berechnung 10, 100, 1000 oder 10000 
mal, abhängig von einer Menüauswahl. 


BIGJOB1: Make-Datei 


ar obj : obi.c bigjob.h 
el2=t pas 2su -W3 -Zp bigjobl.c 


bigjob.res : bigjob.rc bigjob.h 
. re -r bigjob.rc 


en ai .obj Sue. def bigjob.res 
ae /nap, 
We slibe slibcp slibfa os2, bigjob! 
re bigjob.res bigjobi.exe 


BIGJOB1.DEF: Modul-Definitionsdatei 


BIGJOB1 

Re Demo Program No. 1 (C) C. Petzold, 1988’ 
1824 

8192 

ClientkndProc 


BIGJOB1.C: Eine naive Lösung für eine große Aufgabe 
#define INCL_WIN 

Zinclude <os2.h> 

#include <math.h> 

include <stdio.h> 

Jinclude "bigjob.h” 


INT Br (VOID) 


static CHAR szClassName [] = "BigJob1” ; 
HMQ 


HHND benairane, hundClient ; 
NSG gqusg ; 


hab = WinInitialize (ß) ; 
hg = WinCreatesgQueue (hab, 9) ; 


WinRegisterClass (hab, szClassName, GE: 
cs _SYNCPAINT H cs. SIZEREDRAN, 


hwndFrame = WinCreateStdWindow (HWND DESKTOP, 
WS VISIBLE | FS_SIZEBÖRDER | FS_ TITLEBAR 
I FS_SYSMENU | FS_MINMAX Le, 
EEE. "BIGJOB Demo No. 
BL, ‚ID RESOURCE, Ewmdclient) = 


while (WinGetMsg (hab, &qnsg, NULL, 8, 8)) 
WinDispatchNsg (hab, &ansg) ; 


WinDestroyWindow (hwndFrame) ; 
WinDestroyMsgQueue (hag) A 
WinTerminate (hab) ; 


‚ NULL) ; 


return 6 ; 
} 


ULONG EXPENTRY ClientWndProc (HWND hund, USHORT nsg, Bas a} 
ONG mp 


{ 

static SHORT iCalcRep, iCurrentRep = IDM_19 ; 
static SHORT iStatus = STATUS_READY ; 

static ULONG lElapsedTime ; 

double A; 

SHORT 15 


nn (nsg) 


Listing 2 
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MS OS/2 Presentation Manager 


case WM COMMAND: 
sea (LOUSHORT (mp1)) 


case IDM 19: 

case IDM_ 188: 

case IDM_ 1208: 

case IDM_12B88: 
Cnecklienulten (hund, MORE EERD: FALSE); 
iCurrentRep = LOUSHORT (mp!) ; 
re em (hwnd, iCurrentRep, TRUE) ; 
r 


case IDM START: 
Enablefenultem (hund, IDM_START, FALSE) ; 
EnableMenultem (hund, IDM"ABORT, TRUE) ; 


1Status = STATUS _WORKING ; 
WinInvalidateRect (hund, NULL) ; 


iCalcRep = er 
1ElapsedTime = WinGetCurrentTime (hab) ; 


for (A= 1.8, i=8; i < iCalcRep ; i++) 
A = Savage (A) ; 


lElapsedTime = WinGetCurrentTine (hab) - 
lElapsedTine ; 


1Status = STATUS_DONE ; 
HinInvalidateRect (hund, NULL) ; 


EnableMenultem (hund, IDM_START, TRUE) ; 
EnableMenultem (hund, IDMABORT, FALSE) ; 
break ; 
case IDM_ABORT: 
/* Not much we can do here */ 
break ; 


default: 
break ; 


break ; 


case WM PAINT: 
PalntWindow (hund, iStatus, iCalcRep, ° 
1ElapsedTine) = 
break ; 


default 


return WinDefkindowProc (hund, nsg, ap}, mp2) ; 


lc AL; 


Listing 2 (Ende) 


Ich werde für dieses Programm die alternative Fließ- 
komma-Bibliothek verwenden, damit die Berechnung nicht 
durch einen eventuell vorhandenen 80287-Koprozessor 
beeinflußt wird. Das Programm wird über Menüoptionen 
verfügen, die den Start und (wenn möglich) den Abbruch 
der Berechnung vor ihrem Ende erlauben. Die 10000 
Durchläufe des Savage-Benchmarks benötigen auf einem 8- 
MHz-AT etwa 3 Minuten. Schon 10 Durchläufe verletzen 
die 1/10-Sekunden-Regel. 

Wir werden fünf Versionen dieses Programms unter- 
suchen, wobei jede neue Version die Multitasking-Möglich- 
keiten des Presentation Managers ausgefeilter nutzen wird. 
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Die naive Vorgehensweise 


Der einfachste Weg zur Erledigung einer großen Aufgabe 
wird im Programm BIGJOB1 in den Listings I und 2 
gezeigt. Der größte Teil des Codes in der Arbeitsfenster- 
prozedur von BIGJOB1, die ClientWndProc genannt 
wird, behandelt WM_COMMAND-Meldungen aus dem Menü 
des Programms. Wenn eine Option aus dem Menü Repe- 
titions (Durchläufe) gewählt wird, nimmt BIGJOB1 die 
Markierung der aktuellen Option weg und markiert die 
gewählte Option. Wenn Sie aus dem Menü Start wählen, 
gibt BIGJOB1 die Option Abort (Abbruch) frei und 
beginnt mit der Berechnung. Nachdem es die große Auf- 
gabe erledigt hat, gibt es die Start-Option wieder frei und 
beendet die Fensterprozedur. 

Da BIGJOB1 die ganze Berechnung als Reaktion auf 
eine WM_COMMAND-Meldung durchführt, verletzt es ganz 
klar die 1/10-Sekunden-Regel. BIGJOB1 ist ein schlechtes 
Programm. Ich bringe es hier nur deshalb, um zu demon- 
strieren, wie ein solches Programm den Rest des Presenta- 
tion Managers blockiert. 

Während BIGJOB1 seine große Aufgabe erledigt, kön- 
nen Sie nicht zu einem anderen Programm unter dem Pre- 
sentation Manager umschalten. Das System ignoriert 
scheinbar alle Tastatur- und Mauseingaben, bis die Berech- 
nung durchgeführt worden ist. Obwohl die Option Abort 
im Menü von BIGJOB1 vorhanden ist, können Sie weder 
die Tastatur noch die Maus verwenden, um diese Option 
auszuwählen. Sobald Sie mit der großen Aufgabe beginnen, 
müssen Sie warten, bis sie beendet ist, bevor Sie etwas 
anderes machen können. 

Auf den ersten Blick scheint das sehr beunruhigend zu 
sein. Ist der Presentation Manager denn kein Multitasking- 
System? Und wenn er das ist, warum kann ein Programm 
ganz offensichtlich das ganze System blockieren? Was hier 
passiert ist das vorhersagbare Ergebnis der meldungsorien- 
tierten Architektur des Presentation Managers. 


Die Verwendung von Meldungen 


Programme arbeiten unter dem Presentation Manager mel- 
dungsgesteuert. Im Normalfall verbringt ein Programm die 
meiste Zeit in WinGetMsg (die Presentation Manager-Ver- 
sion der GetMessage-Funktion von Windows) und wartet 
auf eine Meldung. 

Jedes Fenster, das von einem Programm angelegt wird, 
hat eine Fensterprozedur, die die Meldungen für dieses 
Fenster bearbeitet. Mindestens eine solche Fensterproze- 
dur, und zwar die Fensterprozedur für die Arbeitsfläche, 
befindet sich im Presentation Manager-Programm. Die 
anderen Fensterprozeduren (zum Beispiel die für den 
Rahmen, die Titelleiste und das Menü) befinden sich in der 
dynamischen Link-Library PMWIND.DLL des Presentation 
Managers. 


MS OS/2 Presentation Manager 


case WM COMMAND: 
unhle” (LOUSHORT (mp1)) 


case IDM_1ß: 

case IDM_12B: 

case IDM_1ARB: 

case IDM_ 12008: 
CheckMenultem (hund, ae FALSE); 
erste Re = LOUSHORT (mp1) ; 
CheckMenultem (hwnd, iCurrenthep, TRUE) ; 
break ; 


case IDM_START: 


if (!WinStartTiner sbeh: tgl Ar 


{ 
WinAlarm (HWND_DESKTOP ‚WA_ERROR); 
En ; 


BIGJOB2: Make-Datei 


bigjob2.obj : ob2.c bigjob.h 
cl =c Kg: 2sw -W3 -Zp bigjob2.c 


bigjob.res : ob.rc bigjob.h 
re -T Dre 


bigjob2.exe : ob2.0bj ‚ngsiop2- def bigjob.res 
link bi I /ali /nap, 

/no slide sl a tr os2, bigjob2 
re bigjob.res bigjob2.exe 


BIGJOB2.DEF: Modul-Definitionsdatei 


BIGJOB2 

rg Demo Program No. 2 (C) C. Petzold, 1988" 
STACKSIZE 8192 
EXPORTS ClientWndProc 


EnableMenultem (hwnd, IDM_START,FALSE); 
EnableMenultem (hwnd, IDNABORT, TRUE); 


iStatus = STATUS WORKING ; 
WinInvalidateRect (hund, NULL) ; 


1CalcRep = iCurrentRep ; 
lElapsedTine = WinGetCurrentTine(hab); 


A=1.8; 
125 


break ; 


IDM_ABORT: 
WinStopTimer (hab, hwnd, ID_TIMER) ; 


iStatus = STATUS READY ; 
WinInvalidateRect (hund, NULL) ; 


EnableMenultem (hwnd, IDM_START, TRUE); 
EnableMenultem (hund, IDM_ABORT,FALSE); 
break ; 


default: 
break ; 


BIGJOB2.C: Timer-Lösung für eine große Aufgabe 
#define INCL_WIN 


include <os2.h> 
include <nath.h> 
Zinclude <stdio.h> 
#include "bigjob.h” 


#define ID_TIMER 1 

INT main (VOID) 
static CHAR szClassName [] = "BigJob2” ; 
HMQ haq ; 
HWND hwndFrame, hwndClient ; 
QMSG ansg ; 
hab = WinInitialize (B) ; 
hg = WinCreateNsgQueue (hab, 9) ; 


WinRegisterClass u szClassNane , ClientWndProc, 
_SYNCPAINT | CS_SIZEREDRAN, 8, NULL) ; 


hwndFrame = WinCreateStdWindow (HWND_ DESKTOP, 
WS VISIBLE | FS_SIZEBÖRDER | FS_TITLEBAR 
I FS_SYSMENU | FS_MINMAX I” FS_MENU, 
szClässName, "Bi Job") Deno No. 2”, 
ÖL, NULL, ID_| CE, &hwndClient) ; 


while (WinGetMsg (hab, &gmsg, NULL, 8, 8)) 
WinDispatchNsg (hab, &qnsg) ; 


WinDestroyWindow (hwndFrane) ; 
WinDestroyMsgQueue (hmg) ; 
WinTerninate (hab) ; 


break ; 
case WM_TIMER: 
A = Savage (A) ; 
if sr: == iCalcRep) 


lElapsedTime = WinGetCurrentTine (hab) - 
lElapsedTine ; 


WinStopTimer (hab, hwnd, ID_TIMER) ; 


1Status = STATUS _DONE ; 
WinInvalidateRect (hund, NULL) ; 


EnableMenultem (hund, IDM_START, TRUE) ; 
return 8 ; BE LO TE (hund, DM ABORT, FALSE) ; 


break ; 


ULONG EXPENTRY ClientWndProc (HWND hund, USHORT msg, ULONG mp1, 


ULONG 2p2) case WM PAINT 


Palntkindow(hund ‚iStatus,iCalcRep, lElapsedTine); 
break ; 


{ 

static double A ; 

static SHORT 1, re iCurrentRep = IDM_18 ; 
TA 


default 


static SHORT 1Status = TUS_READY ; R 
3 return HinDefWindowProc (hwnd, msg, mp1, mp2) ; 


static ULONG 1ElapsedTime ; 


ei (nsg) en BL ; 


Listing 3 Listing 3 (Ende) 
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Einige der Meldungen für ein Fenster werden in der 
Meldungsqueue des Programms gespeichert. Diese Mel- 
dungen werden »gequeute« Meldungen genannt und man 
sagt, daß sie in die Queue »eingetragen« wurden. Die ge- 
queueten Meldungen werden aus der Meldungsqueue gele- 
sen, wenn ein Programm WinGetMsg aufruft und werden 
mit WinDispatchMsg an die Fensterprozedur weitergelei- 
tet. Andere Meldungen werden direkt, unter Umgehung der 
Meldungsqueue, an die Fensterprozedur geschickt. 

Ganz gleich, ob eine Meldung in die Meldungsqueue 
eingetragen oder direkt an die Fensterprozedur geschickt 
wird und ganz gleich, ob sich die Fensterprozedur im Pro- 
gramm oder in einer dynamischen Link-Library befindet, 
Meldungen an Fenster, die von einem Ausführungsthread 
erzeugt werden, werden immer in diesem Thread verarbei- 
tet. Ein bestimmter Thread kann zu einem Zeitpunkt nur 
eine Aufgabe ausführen. Ein Thread kann nicht mit sich 
selbst im Multitasking-Betrieb laufen. Das scheint ganz klar 
zu sein, doch die meldungsorientierte Architektur des 
Presentation Managers verschleiert diese simple Tatsache. 

Wenn Sie aus dem Menü von BIGJOB1 Start wählen, 
beginnt das Programm mit der großen Aufgabe. Sie ver- 
suchen dann, mit der Tastenkombination zu 
einem anderen Programm umzuschalten. Das Fenster, daß 
diese Tastendrücke verarbeiten muß, ist das Rahmenfenster 
von BIGJOB1. Die Fensterprozedur für das Rahmenfenster 
muß im selben Thread laufen wie das Arbeitsfenster, doch 
das Arbeitsfenster ist gerade emsig damit beschäftigt, die 
große Aufgabe zu erledigen. Das bedeutet, daß die Tasta- 
turmeldung nicht eher bearbeitet werden kann, als 
bis die Berechnung beendet ist, BIGJOB1 ClientWnd- 
Proc verläßt und dann WinGetMsg aufruft, um die Mel- 
dung aus der Queue zu lesen. Das erklärt, warum der Pre- 
sentation Manager Tastatureingaben scheinbar ignoriert, 
während BIGJOB1 rechnet. 


Serialisierung der Eingabe 
Es scheint jedoch einen Weg zu geben, dies zu umgehen. 
Wie Sie wissen, kann man ein anderes Fenster auch mit der 
Maus aktivieren. Vielleicht funktioniert das. 

Um diese Möglichkeit zu prüfen, müssen Sie den Maus- 
zeiger zunächst im Fenster eines anderen Programms posi- 
tionieren und dann über die Tastatur Start aus dem Menü 
von BIGJOB auswählen. Während das Programm rechnet 
drücken Sie die Maustaste und ... nichts passiert. 

Auch dies ist zunächst wieder etwas beunruhigend. Da 
der Presentation Manager ein echtes Multitasking-System 
ist, sollte das andere Programm den Mausklick lesen kön- 
nen, selbst wenn BIGJOB1 rechnet. Der Presentation 
Manager sollte es ebenso erlauben, daß ein anderes Pro- 
gramm aktiviert wird. 

Das passiert aus einer Reihe von Gründen jedoch nicht. 
Zum einen serialisiert der Presentation Manager alle Tasta- 
tur- und Mauseingaben in einer System-Meldungsqueue. 
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Die Eingaben werden Meldung für Meldung an die Mel- 
dungsqueue einer Anwendung übergeben, abhängig davon, 
welches Fenster den Eingabefokus hat (bei der Tastatur) 
und welches Fenster sich unter dem Mauszeiger befindet. 

Die Serialisierung von Maus- und Tastatureingaben in 
einer System-Meldungsqueue ist notwendig, um die Puffe- 
rung dieser Benutzereingaben korrekt handhaben zu kön- 
nen. Einer der Tastendrücke oder Mausklicks in der 
System-Meldungsqueue könnte bewirken, daß sich das 
aktive Fenster und das Fokusfenster ändern. Darauffol- 
gende Tastatureingaben müssen an das neue Fenster gehen. 
Dies würde nicht funktionieren, wenn Maus- und Tasta- 
tureingaben nicht in derselben Reihenfolge an Anwendun- 
gen übergeben würden, in der sie in die System-Meldungs- 
queue eingetragen werden. Deshalb kann eine Tastatur- 
oder Mausmeldung nicht eher an eine bestimmte Anwen- 
dung übergeben werden, bis alle vorherigen Tastatur- und 
Mausmeldungen verarbeitet worden sind. 

In diesem speziellen Fall können andere Anwendungen 
solange keine Mausmeldung lesen, bis BIGJOB1 alle seine 
Tastatureingaben verarbeitet hat. Bei der Tastatureingabe, 
die noch nicht verarbeitet wurde, handelt es sich um das 
Loslassen der Taste, das bewirkte, daß das Menü die 
Meldung WM_COMMAND geschickt hat, mit der die Berech- 
nung gestartet wurde. 

So wiedersetzt sich BIGJOB1 nicht nur Tastatur- und 
Mauseingaben, es hindert auch noch alle anderen Pro- 
gramme, die gerade unter dem Presentation Manager lau- 
fen, daran, Tastatur- oder Mauseingaben zu erhalten. 

Selbst wenn ein anderes Programm einen Mausklick 
lesen könnte, kann der Presentation Manager den Eingabe- 
fokus nicht von BIGJOB1 an ein anderes Programm abge- 
ben, während BIGJOB1 damit beschäftigt ist, Berechnun- 
gen durchzuführen. Um den Eingabefokus zu ändern, muß 
der Presentation Manager die Meldung WM_SETFOCUS an 
das Fenster schicken, das den Eingabefokus verliert. Diese 
WM_SETFOCUS-Meldung wird blockiert, weil das Fenster, 
das die Meldung erhalten muß, ein Teil des BIGJOBI- 
Threads ist und BIGJOB1 ist damit beschäftigt, seine große 
Aufgabe zu erledigen. 

Meldungen sind etwas anderes als Hardware-Interrupts. 
Auch wenn einer Fensterprozedur als Ergebnis eines Win- 
DefWindowProc-Aufrufs und einer Fensterprozedur als 
Ergebnis änderer Presentation Manager-Funktionen eine 
Meldung geschickt werden kann, sind dies Beispiele für die 
Rekursion in Fensterprozeduren. Meldungen unterbrechen 
nicht preemptiv einen Thread und setzen die Ausführung 
irgendwo anders in dem gleichen Thread fort. 

Nachdem Sie nun gesehen haben, wie BIGJOB1 die 
Tastatur- und Mauseingaben im Presentation Manager 
effektiv ausschaltet, sollte der Grund für die 1/10-Sekun- 
den-Regel klar sein. Presentation Manager-Programme 
müssen ständig mit dem System kommunizieren und ihre 
Meldungen zügig lesen und verarbeiten. 


ron = 


MS OS/2 Presentation Manager 


BIGJOB3: Make-Datei BpetaN (nsg) 


BLEIBT: obj : ob3.c bigjob.h case WM COMMAND: 
=5 A 2sw -W3 -Zp bigjob3.c Mat (LOUSHORT (mp1) ) 


bigjob.res : ob.rc bigjob.h case IDM_1B: 
re -r buejehere case IDM_ 188: 


case IDM 1888: 
bigjob3.exe In .obj a2: def bigjob.res case IDM_ 10888: 
link bigjob Ay ah map, CheckMenultem(hund, en: FALSE); 
/nod_slibe slibcp Ahr 0s2, bigjob3 euere = LOUSHORT (mp1 

rc bigjob.res bigjob3.exe ei em(hwnd, iCurrentRep, TRUE); 
reak ; 
IDM_STÄRT: 
EnableMenultem(hwnd, IDM_START,FALSE); 
EnableMenultem(hund, IDM_ABORT, TRUE) ; 


BIGJOB3.DEF: Modul-Definitionsdatei iStatus = STATUS WORKING ; 
WinInvalidateRect (hund, NULL) ; 
NAME BIGJOB3 


DESCRIPTION Er Demo Program No. 3 (C) C. Petzold, 1988’ iCalcRep = iCurrentRep ; - 
HEAPSIZE 82 bContinueCalc = TRUE ; 


1 
STACKSIZE 8192 lElapsedTine = WinGetCurrentTime(hab); 
EXPORTS ClientkndProc 
gusg.msg = WM_NULL ; 


for (A = 1.8, i = 8; i < 1CalcRep;i++) 


A = Savage (A) ; 
BIGJOB3.C: PeekMessage für eine große Aufgabe 
while (WinPeekMsg an ara 


#define INCL WIN L, 8, D, 
a PM_NOREMOVE) ) 


Zinclude <os2.h> { 
#include <nath.h> if (qmsg.nsg == WM_QUIT) 
break ; 


#include <stdio.h> 
#include "bigjob.h” WingetM (hab, 
n sg 
Le B; 
WinDispatchiisg" (hab, &ansg); 


INT ro (VoID) 
static CHAR szClassName [] = "BigJob3” ; 
HMQ hang ; if (tbContinueCalc) 
HWND hwndFrame, hwndClient ; break ; 
QMSG qnsg ; } 


hab = WinInitialize (8) ; if (tbContinueCale || 
hag = WinCreateMsgQueue (hab, #) ; qusg.usg == WM_QUIT) 


break ; 
WinRegisterClass (hab, szClassName, ClientkndProc, 
CS_SIZEREDRAW, 9, NULL) ; lElapsedTime = WinGetCurrentTime(hab)- 


lElapsedTine ; 


hwndFrane = WinCreateStdWindow (HWND DESKTOP, 
WS_VISIBLE | FS_SIZEBÖRDER | Fs _TITLEBAR if erg H 
I FS_SYSMENU | FS_MINMAX I”FS_MENU, 2: == WM QUIT) 
ee "Demo No. 3”, Istatus = STATUS _READY ; 
‚„ NULL, ID_RE CE, &hwndClient) H else 
iStatus = STATUS_DONE ; 


while (WinGetMsg (hab, &qmsg, NULL, 8, 8)) 
WinDispatchNsg (hab, &ansg) ; WinInvalidateRect (hund, NULL) ; 


WinDestroyWindow (hwndFrame) ; EnableMenultem(hwnd, IDM_START, TRUE); 
WinDestroyMsgQueue {hag) ; EnableMenultem(hwnd, IDMABORT, FALSE); 
WinTerninate (hab) ; break ; 
case IDM ABORT: 
return 9 ; bContinueCalc = FALSE ; 
break ; 
default: 
break ; 
ULONG EXPENTRY ClientWndProc (HWND hund, USHORT msg, ULONG mp1, 
ULONG ap2) en 
{ case WM PAINT: 
static BOOL bContinueCalc = FALSE ; PaintKindow(hwnd, iStatus,iCalcRep,lElapsedTime); 


static SHORT iStatus = STATUS READY ; break ; 


static SHORT iCalcRep, iCurrentRep = "IDM_ 18 ; default: 
static ULONG 1ElapsedTime $ } return WinDefkindowProc (hund, msg, mpl, mp2) ; 


double KR: 
SHORT i; sa BL ; 


SG qusg ; 


Listing 4 Listing 4 (Ende) 
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MS OSJ/2 Presentation Manager 


Nicht genau wie Windows 


So schlecht BIGJOB1 auch sein mag, der Presentation 
Manager kann auch dann den Multitasking-Betrieb fortset- 
zen, wenn BIGJOB1 läuft. Dies ist ein Unterschied zwi- 
schen dem Presentation Manager und Windows. 

Wenn Sie eine Windows-Version von BIGJOB1 unter 
Windows zusammen mit dem Uhr-Programm laufenlassen, 
bleibt die Uhr stehen, während BIGJOB1 rechnet. Unter 
Windows kann zu einem Zeitpunkt nur ein Programm lau- 
fen. Wenn Sie BIGJOB1 jedoch unter dem Presentation 
Manager zusammen mit dessen Version der Uhr laufenlas- 
sen (wie zum Beispiel der aus meinem Buch Programming 
the OS/2 Presentation Manager, Microsoft Press, 1988), 
werden Sie sehen, daß die Uhr weiterläuft, während 
BIGJOB1 rechnet. Die Uhr und BIGJOB1 laufen gleich- 
zeitig. 

Dies funktioniert durch Setzen eines Timers und durch 
Verarbeitung einer WM_TIMER-Meldung in jeder Sekunde. 
Eine WM_TIMER-Meldung braucht nicht mit Tastatur- und 
Mauseingaben serialisiert werden. Die Uhr kann weiterhin 
diese Meldungen erhalten, selbst wenn BIGJOB1 Tastatur- 
und Mauseingaben blockiert hat. 


Der Einsatz eines Timers 


Wenn Sie erkannt haben, daß BIGJOB1 ein sehr schlechtes 
Presentation Manager-Programm ist, haben Sie das Pro- 
blem, es so umzustrukturieren, daß es richtig arbeitet. Die 
Verwendung eines Timers bei der Uhr scheint eine Lösung 
aufzuzeigen: Man kann eine große Aufgabe in kleine Teile 
aufteilen, den Presentation Manager-Timer setzen und 
jeden kleinen Teil beim Empfang einer WM_TIMER-Mel- 
dung ausführen. Dies ist eine Lösung, die sowohl unter 
Windows, als auch unter dem Presentation Manager funk- 
tioniert. 

Das Programm BIGJOB2 verwendet einen Timer für 
die große Aufgabe. Die Dateien BIGJOB2, BIGJOB2.C 
und BIGJOB2.DEF sind in Listing 3 zu sehen. Für die 
Kompilierung von BIGJOB2 werden auch die Dateien 
BIGJOB.H und BIGJOB.RC aus Listing 1 benötigt. 

Wenn Sie die Option Start aus dem Menü von BIG- 
JOB2 wählen, ruft BIGJOB2 WinStartTimer auf, um den 
Timer zu starten, es schaltet die Start-Option aus, die 
Abort-Option ein und initialisiert einige Variablen. Die 
Savage-Berechnung wird einmal bei jeder WN_TIMER-Mel- 
dung ausgeführt. Bei 1000 Durchläufen wird die große Auf- 
gabe also nach 1000 WM_TIMER-Meldungen beendet. 

WM_TIMER-Meldungen sind Meldungen mit niedriger 
Priorität. Wenn die Meldungsqueue Tastatur- oder Maus- 
meldungen enthält, werden diese Meldungen vor einer 
WM_TIMER-Meldung aus der Meldungsqueue gelesen und 
verarbeitet. So kann BIGJOB2 weiter Tastatur- und Maus- 
eingaben lesen, und es dem Benutzer gleichzeitig ermög- 
lichen, Abort aus dem Menü von BIGJOB2 zu wählen, das 
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Fenster von BIGJOB2 zu bewegen oder zu vergrößern oder 
zu einem anderen Programm zu wechseln. Das ganze 
System, auch BIGJOB2 selbst, arbeitet die ganze Zeit nor- 
mal, während BIGJOB2 seine Berechnungen durchführt. 


Timer-Probleme 


Der Timer-Ansatz ist für BIGJOB2 nicht schlecht, es gibt 
jedoch Fälle in denen ein Timer völlig unpassend wäre. 

Ein Programm, das den Timer verwendet, muß laufend 
die Verarbeitungsschleife bei jeder WM_TIMER-Meldung 
betreten und wieder verlassen. Dies kann man leicht struk- 
turieren, wenn es sich um eine Schleife handelt, es wird 
jedoch bei komplizierteren Aufgaben mit mehreren ver- 
schachtelten Schleifen zum Alptraum. 

Darüber hinaus verlangsamt der Timer die große Auf- 
gabe. Es ist nicht möglich, WA_TIMER-Meldungen öfter zu 
erhalten, als dies die Hardware-Uhr zuläßt. Unter OS/2 
bedeutet dies, daß das Programm nur alle 31,25 Millisekun- 
den eine WM_TIMER-Meldung erhält. BIGJOB2 benötigt 
jedoch weniger als 20 Millisekunden (auf einem 8-MHz- 
AT) zur Verarbeitung jeder WM_TIMER-Meldung. Da die 
Berechnung im Takt mit dem Timer erfolgt, wird die 
Berechnung auf einem 20-MHz-80386-System um keinen 
Deut schneller erledigt. 

Als allgemeine Lösung für die Erledigung einer großen 
Aufgabe muß der Timer-Ansatz also eindeutig verworfen 
werden. 


PeekMessage 


Eine andere häufig verwendete Lösung unter Windows be- 
steht in der Verwendung der Funktion PeekMessage 
(WinPeekMsg unter dem Presentation Manager). Die 
Funktion PeekMessage gleicht der Funktion GetMes- 
sage. Unter Windows prüft die Funktion PeekMessage 
zuerst, ob irgendwelche Meldungen in der Meldungsqueue 
des Programms warten. Wenn das so ist, füllt PeekMes- 
sage die Meldungsstruktur mit der nächsten Meldung aus 
der Queue und gibt einen Wert ungleich Null zurück. 

Wenn die Meldungsqueue des Programms, daß Peek- 
Message aufruft, leer ist, schaltet Windows zu einem Pro- 
gramm um, dessen Meldungsqueue nicht leer ist, um die- 
sem Programm die Bearbeitung seiner Meldungen zu 
ermöglichen. (Dies wird oft »Übergabe« an ein anderes 
Programm genannt.) Wenn in den Meldungsqueues der 
Programme keine Meldungen übrig bleiben, übergibt 
PeekMessage die Steuerung wieder an das Original- 
programm und gibt Null zurück. 

PeekMessage ermöglicht allen Windows-Programmen 
die Verarbeitung offener Meldungen, gibt die Steuerung 
jedoch dann an das Programm zurück, das PeekMessage 
aufgerufen hat, nachdem die ganze Meldungsverarbeitung 
beendet ist. Die Verwendung von PeekMessage erlaubt es 
einem Programm, eine große Aufgabe zu erledigen, wäh- 
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rend es ihm und auch anderen Programmen periodisch 
möglich ist, ihre Meldungen zu verarbeiten. Mehrere Win- 
dows-Programme, einschließlich SPOOLER und TERMI- 
NAL, verwenden PeekMessage in dieser Art, um Multi- 
tasking zu simulieren. Programme, die drucken, verwenden 
häufig PeekMessage, damit der Benutzer den Druckvor- 
gang mit einem Dialogfeld abbrechen kann. 

Die Funktion WinPeekMsg des Presentation Managers 
gleicht PeekMessage. Im Presentation Manager wird 
WinPeekMsg jedoch von einem Programm für die Verar- 
beitung seiner eigenen Meldungen verwendet und nicht zur 
Übergabe der Ausführung an andere Programme. Multi- 
tasking wird unter dem Presentation Manager normaler- 
weise dann ausgeführt, wenn ein Programm die Verarbei- 
tung der Tastatur- und Mauseingaben nicht blockiert. Die 
Funktion WinPeekMsg bietet eine gute Lösung für das 
Problem der großen Aufgabe. BIGJOB3 in Listing 4 zeigt, 
wie es gemacht wird. 

Wie BIGJOB2 erledigt BIGJOB3 alle Berechnungen als 
Reaktion auf eine WM_COMMAND-Meldung. In der Berech- 
nungsschleife ruft BIGJOB3 WinPeekMsg auf, um festzu- 
stellen, ob sich in seiner Meldungsqueue Meldungen befin- 
den. Wenn das der Fall ist, entfernt es sie mit WinGetMsg 
und leitet sie mit WinDisPatchMsg an eine Fensterpro- 
zedur wie die normale Meldungsschleife in main weiter. 

Bei einer dieser Meldungen könnte es sich um eine 
WM_COMMAND-Meldung handeln, die erzeugt wird, wenn der 
Benutzer aus dem Menü Abort wählt. BIGJOB3 verwen- 
det bContinueCalc als Flag für den Abbruch. 

Sie werden bemerkt haben, daß für die Meldung 
WM_QUIT eine besondere Verarbeitung erforderlich ist. 
Diese Meldung wird vom Presentation Manager als Stan- 
dardantwort auf die Auswahl von Close im Systemmenü in 
die Meldungsqueue eingetragen. Die Meldung WM_QUIT 
sollte in der Fensterprozedur nicht aus der Queue entfernt 
werden. Statt dessen verläßt BIGJOB3 die Fensterprozedur, 
damit die WA_QUIT-Meldung von der main-Funktion aus- 
gelesen werden kann. 

Auch wenn diese Meldungs-Vorausschau in Windows- 
und Presentation Manager-Programmen gewöhnlich gut 
funktioniert, ist sie in der Praxis immer etwas unsauber. Die 
Funktionen PeekMessage und WinPeekMsg müssen oft 
genug aufgerufen werden, um ein gutes Antwortverhalten 
des Systems zu erzielen, und es wird eine unverhältnismäßig 
große Menge von Programmcode benötigt. Wenn die große 
Aufgabe abgebrochen werden muß, ist es gelegentlich 
schwierig, die Berechnungsschleife in einer strukturierten 
Art und Weise zu verlassen. Kurz gesagt, ein Programm mit 
WinPeekMsg sieht oft arg verunglückt aus: 


Ein zweiter Thread 


Die Lösungen von BIGJOB2 und BIGJOB3 können sowohl 
unter Windows als auch beim Presentation Manager ver- 
wendet werden. Lassen Sie uns nun etwas tun, was unter 


Windows unmöglich, beim Presentation Manager jedoch 
ganz natürlich ist: Wir wollen für die große Aufgabe einen 
zweiten Ausführungsthread erzeugen. 

Wenn ein Programm mehrere Ausführungsthreads ent- 
hält, laufen dieses Threads gleichzeitig. Alle Threads in 
einem Prozeß teilen sich die Ressourcen des Programms, 
zum Beispiel offene Dateien, Speicher, Semaphore und 
Queues, doch jeder Thread verfügt über einen eigenen 
CPU-Zustand, eigene Zuteilungspriorität und einen eigenen 
Stack. 

In einem Programm sieht ein zweiter Ausführungs- 
thread wie eine Funktion aus. Alle lokalen automatischen 
Variablen in einer Threadfunktion sind privates Eigentum 
dieses Threads, denn sie werden auf dem Stack des Threads 
gespeichert. Lokale statische Variablen in der Threadfunk- 
tion können von allen Threads, die auf dieser Funktion 
basieren, gemeinsam verwendet werden. 

Bei der Programmierung für den Presentation Manager 
fallen Threads in zwei Kategorien: Ein Thread ist entweder 
ein Thread mit oder ohne Meldungsqueue. Ein Thread wird 
zu einem Thread mit Meldungsqueue, wenn er Win- 
CreateMsgQueue aufruft. Er wird wieder ein Thread ohne 
Meldungsqueue, wenn er WinDestroyMsgQueue aufruft. 

Ein Presentation Manager-Programm legt immer in 
mindestens einem Thread eine Meldungsqueue an. Ein 
Thread muß eine Meldungsqueue anlegen, bevor er Fenster 
erzeugen kann. Die Meldungsqueue wird dazu verwendet, 
um die Meldungen für alle Fenster in dem Thread zu 
speichern. Andere Threads in einem Presentation Manager- 
Programm brauchen jedoch keine Meldungsqueue anlegen, 
wenn sie keine Fenster erzeugen. 


Beschränkungen von Threads 


In einem Presentation Manager-Programm haben Threads 
ohne Meldungsqueue gewisse Vorteile gegenüber solchen 
mit Meldungsqueue - aber auch einige Nachteile. 

Erfreulich ist, daß ein Thread ohne Meldungsqueue 
nicht an die 1/10-Sekunden-Regel gebunden ist, denn er 
empfängt oder verarbeitet keine Meldungen, er braucht 
nicht zu befürchten, daß er in Threads mit Meldungsqueue 
die Meldungsverarbeitung blockiert. Somit eignet sich ein 
Thread ohne Meldungsqueue oft ideal für große Aufgaben. 

Unerfreulich ist, daß Threads ohne Meldungsqueue in 
der Verwendbarkeit von Presentation Manager-Funktionen 
eingeschränkt sind. Im Prinzip kann ein Thread ohne eine 
Meldungsqueue keine Fenster anlegen, keine Meldungen an 
einen Thread mit Meldungsqueue schicken und keine Funk- 
tionen aufrufen, die dazu führen, daß Meldungen an eine 
Fensterfunktion geschickt werden. 

Einige dieser Beschränkungen sind sofort einsichtig: Ein 
Thread ohne Meldungsqueue kann kein Fenster anlegen, 
weil er keine Queue hat, in der er Meldungen für das Fen- 
ster speichern könnte. 
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BIGJOB4: Make-Datei 
a et u eg Se c A Blelobd. 
ob4.c 


bigjob.res : bigjob.rc bigjob.h 
re -r bigjob.rc 


bigjob4.exe : he ob4.obj BIBIoHt- def bigjob.res 
link bi ee map, 
/ Ns ibe sl bcp slibfa 0s2, bigjob4 
rc bigjob.res bigjob4.exe 


BIGJOB4.DEF: Modul-Definitionsdatei 


NANE BIGJOB4 
DESCRIPTION "BigJob Demo Program No. 4 (C) C. Petzold, 1988’ 
HEAPSIZE ın24 


STACKSIZE 8192 
EXPORTS ClientkndProc 


BIGJOBA.C: Ein zweiter Thread für die große Aufgabe 


(WM_USER + 8) 
#define WM_CALCTABORTED (WM_USER + 1) 


VOID FAR SecondThread (VOID) ; 


BOOL bContinueCalc = FALSE ; 
HWND hwndClient ; 

SHORT ICalcRep ; 

LONG 1SemTri er ; 

TID idThre 

UCHAR cThreadStäck [4996] ; 


INT Zu (VOID) 
age: CHAR szClassName [] = "BigJob4” ; 


HWND 
NSG 


hab = WinInitialize (B) ; 
hag = WinCreateisgQueue (hab, 2) ; 


WinRegisterClass (hab, Berlassme: ClientWndProc, 
;_SIZEREDRAW, 8, NULL) ; 


hwndFrame = WinCreateStdWindow (HWND DESKTOP, 
WS VISIBLE | FS_SIZEBÖRDER | FS_ TITLEBAR 
I FS_SYSMENU En FS_MINMAX I” FS_MENU, 
szClassName, "BigJob Demo No. 4”, 
öL, NULL, ID RES ‚ &hwndClient) ; 


while (WinGe (hab, & ‚ NULL, 8, 8)) 
WinDis) eier (hab, &dasg) ; ; 
DosSus; ead ni dThread) ; 
Windestrojisg@ueue (naq) ı 
stro; ; 
WinTersminate (hab) ; ; 
return 8 ; 


Listing 5 
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ULONG EXPENTRY ClientkndProc (HWND hund, USHORT nsg, nun we 1 
ONG np 


{ 

static SHORT iCurrentRep = IDM_18 ; 
static SHORT iStatus = STATUS _READY ; 
static ULONG lElapsedTine ; 


RE (msg) 


case WM_CREATE: 
DosSenSet (&1SemTrigger) ; 


if (DosCreateThread (SecondThread, &idThread, 
cThread$Stack + sizeof cThreadStack)) 


WinAlarm (HWND_DESKTOP, WA_ERROR) ; 
break ; 


case WM COMMAND: 
.. (LOUSHORT (mp1)) 


case IDM_18: 
case IDM 180: 
case IDM 1098: 
case IDM_10888: 
CheckMenultem(hund, POeEenENG: FALSE); 
iCurrentRep = LOUSHORT (mp 
rs gen ea) TRUE); 


IDM_START: 
iStatus = STATUS WORKING ; 
HinInvalidateRect (hund, NULL) ; 


iCalcRep = IereneBep z 
bContinueCalc = TRUE ; 
DosSenClear (&1SenTrigger) ; 


EnableMenultem(hwnd, IDM_START,FALSE); 
EnableMenultem(hwnd, IDM_ABORT, TRUE) ; 
break ; 


IDM_ABORT: 
bContinueCalc = FALSE ; 


EnableMenultem(hwnd, IDM_ABORT,FALSE); 
break ; 


default: 
break ; 


break ; 


case WM CALC DONE: 

iStatus = STATUS_| pe 
lElapsedTine = $ 
WinInvalidateRec "ana; NULL) ; 


EnableMenultem (hund, IDM_START, TRUE) ; 
EnableMenultem (hund, IDM_ABORT, FALSE) r 


break ; 


case WM CALC_ABORTED: 
1Status = STATUS READY ; 
WinInvalidateRect (hund, NULL) ; 


EnableMenultem (hwnd, IDM_START, TRUE) ; 
Fe - 
case WM PAINT: 
PaintWindow(hund ‚iStatus, iCalcRep,lElapsedTime); 
break ; 
default: 
return WinDefkindowProc (hund, msg, mp1, mp2) ; 


} 
FeuRE BL ; 


Listing 5 (Fortsetzung) 
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voID Er SecondThread () 


while (1) 
DosSemhait (&1SemTrigger, -IL) ; 
lTime = KinGetCurrentTime (hab) ; 


for “ =1.8, i=8; i < iCalcRep ; i++) 
if (tbContinueCalc) 
break ; 


\ = Savage (A) ; 


lTine = WinGetCurrentTime (hab) - lTine ; 
DosSenSet (&1SemTrigger) ; 


if (bContinueCalc) 
WinPostMsg(hwndClient, WM_CALC_DONE, 1Time, BL); 


else 
' WinPostMsg(hwndClient, WM_CALC_ABORTED, BL, AL); 


Listing 5 (Ende) 


Ein Thread ohne Meldungsqueue kann jedoch einige 
Funktionen aufrufen, die Fenster in einem Thread mit 
Meldungsqueue beeinflussen. Beispielsweise kann ein 
Thread ohne Meldungsqueue eine Handle auf einen Prä- 
sentationsbereich in einem Fenster anfordern, das von 
einem Thread mit Meldungsqueue angelegt wurde, und 
dadurch etwas in diesem Fenster anzeigen. \ 

Threads ohne Meldungsqueue können keine Meldungen 
an Thread mit Meldungsqueue schicken. Die Funktion 
WinSendMsg darf nicht verwendet werden. Auch können 
sie keine Funktionen aufrufen, die Meldungen schicken. Die 
Funktion WinDestroyWindows kann zum Beispiel von 
einem Thread ohne Meldungsqueue nicht aufgerufen wer- 
den, weil sie die Meldung WM_DESTROY an eine Fenster- 
funktion schickt. Die Funktionen, die für Threads ohne 
Meldungsqueue verboten sind, sind in der Programmier- 
dokumentation des Presentation Managers aufgeführt. 

Obwohl ein Thread ohne Meldungsqueue keine Mel- 
dungen mit WinSendMsg schicken kann, kann der Thread 
eine Meldung mit WinPostMsg eintragen. Diese Funktion 
schreibt die Meldung in die Meldungsqueue eines Threads 
und kehrt sofort zurück. 


Semaphore 


Mehrere Threads in einem einzigen Prozeß müssen oft mit- 
einander auf viele Arten kommunizieren. Die Ausführung 
von Threads muß koordiniert werden, damit sie sich nicht 
gegenseitig auf die Füße treten. Dies erfordert einige 
Abstimmung. Oft müssen Threads sich gegenseitig auch 
etwas signalisieren oder Daten übergeben. 


Ein Thread mit Meldungsqueue kommuniziert mit 
einem Thread ohne Meldungsqueue in der Regel über 
Semaphore. Ein Thread ohne Meldungsqueue kommuni- 
ziert mit einem Thread mit Meldungsqueue durch das Ein- 
tragen von Meldungen. Beide Threads können auch auf 
gemeinsame globale Variablen zugreifen. 

Das Programm BIGJOBS4 in Listing 5, das einen Thread 
ohne Meldungsqueue für die große Aufgabe einsetzt, 
demonstriert diese Kommunikation. 

Die globale Varibale 1SemTrigger ist ein RAM-Sema- 
phor. Dieses Semaphor wird bei der Meldung WM_CREATE 
in der Prozedur ClientWndProc gesetzt. Die Fensterpro- 
zedur erzeugt dann mit einem Aufruf der OS/2-Funktion 
DosCreateThread einen zweiten Thread, wobei Second- 
Thread die Threadfunktion ist. 

SecondThread wartet darauf, daß 1SemTrigger 
zurückgesetzt wird. ClientWndProc setzt das Semaphor 
zurück, wenn der Benutzer aus dem Menü von BIGJOB4 
Start auswählt. SecondThread führt dann die Berech- 
nungen aus. Wenn er fertig ist, übergibt er die Meldung 
WM_CALC_DONE an die Fensterprozedur. (Dabei handelt es 
sich um eine benutzerdefinierte Meldung.) Die für die 
Berechnung benötigte Zeit wird der Fensterprozedur in der 
Variablen 1Parami übergeben, die ein Bestandteil dieser 
Meldung ist. 


Abbruch der Berechnung 


BIGJOB4 erlaubt es dem Benutzer auch, die Berechnung 
abzubrechen. Wenn aus dem Menü Abort gewählt wird, 
setzt die Fensterprozedur die globale Variable bCon- 
tinueCalc auf FALSE und schaltet die Menüoption 
Abort aus. 

SecondThread überprüft diese Variable bContinue- 
Calc bei der Berechnung und verläßt die Schleife, wenn die 
Variable nicht länger ungleich Null ist. Der Thread setzt 
dann das Semaphor und übergibt die Meldung 
WM_CALC_ABORTED an das Fenster. Bei Erhalt dieser Mel- 
dung schaltet das Arbeitsflächenfenster die Option Start 
wieder ein. Das Semaphor ist bereits gesetzt, Second- 
Thread kann also mit einer weiteren Berechnung erst wei- 
termachen, wenn wieder Start gewählt wird. Dies ist ein 
Beispiel für die einfache Kommunikation zwischen Threads. 

Beachten Sie, daß das Semaphor nur zum Blockieren 
und Freigeben des Threads ohne Meldungsqueue verwen- 
det wird. Ein Thread mit Meldungsqueue sollte nicht auf 
ein Semaphor warten müssen, da dies die 1/10-Sekunden- 
Regel verletzen könnte. Wenn es absolut notwendig ist, 
kann ein Thread ohne Meldungsqueue einen mit Mel- 
dungsqueue für ganz kurze Zeit mit der Funktion DosSus- 
pendThread oder DosEnterCritSec anhalten. Dies ist 
gelegentlich hilfreich, wenn beide Threads auf globale 
Variablen zugreifen. (In BIGJOB4 ist das beim Zugriff der 
beiden Threads auf bContinueCalc nicht notwendig, weil 
darauf mit einem Maschinenbefehl zugegriffen wird.) 
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Der Thread mit Meldungsqueue in BIGJOB4 ruft Dos- 
SuspendThread auf, um SecondThread nach dem Ver- 
lassen der Meldungsschleife in main und vor dem Löschen 
des Fensters und der Meldungsqueue anzuhalten. 


In Threads denken 


Threads ohne Meldungsqueue sind für Presentation Mana- 
ger-Programme, die Eingaben anders als über die Tastatur 
oder die Maus erhalten, nahezu unentbehrlich. Ein klares 
Beispiel dafür ist ein Kommunikationsprogramm. Ein sol- 
ches Programm würde im Thread mit Meldungsqueue ein 
Arbeitsfenster haben, daß die Tastaturmeldungen bearbei- 
tet, Zeichen mit DosWrite an die serielle Schnittstelle 
schickt und (wenn lokales Echo eingeschaltet ist) das Zei- 
chen auch auf die Fensteroberfläche schreibt. 

Der Thread ohne Meldungsqueue liest die Schnittstelle 
mit der Funktion DosRead. Wenn sie sehr effektiv einge- 
setzt wird, kehrt diese Funktion nicht eher zurück, als bis 
ein Zeichen von der seriellen Schnittstelle gelesen wurde. 
Ein Thread mit Meldungsqueue sollte DosRead nicht für 
die Eingabe von einer seriellen Schnittstelle verwenden, 
weil dadurch die 1/10-Sekunden-Regel verletzt werden 
könnte. Wenn der Thread ohne Meldungsqueue ein Zei- 
chen liest, kann er eine benutzerdefinierte Meldung an das 
Fenster übergeben. Das Arbeitsfenster verarbeitet die 
Meldung durch Anzeige des Zeichens im Fenster. 

Ein Presentation Manager-Programm, das Queues für 
die Kommunikation zwischen Prozessen verwendet, sollte 
auch zum Lesen einer Queue einen Thread ohne Meldungs- 
queue anlegen. Der Thread ohne Meldungsqueue ruft die 
Funktion DosReadQueue mit auf Null gesetztem No-Wait- 
Flag auf, so daß der Thread blockiert wird, bis etwas in der 
Queue ist. 

In BIGJOB4 wird der zweite Thread immer dann ange- 
legt und freigegeben, wenn er die große Aufgabe erledigen 
muß. Wenn ein Programm viele große Aufgaben in vielen 
verschiedenen Threadfunktionen zu erledigen hat, würde es 
am besten sein, nicht alle diese Threads schon zu Beginn 
anzulegen, sondern jeden einzelnen erst dann, wenn er 
benötigt wird. Wenn ein Thread seine große Aufgabe erle- 
digt hat, kann er eine Meldung an das Arbeitsfenster über- 
geben und sich selbst durch einen Aufruf von DosExit mit 
0 als erstem Parameter beenden. 


Objektfenster 


BIGJOB4 zeigt, wie ein Programm große Aufgaben mit 
einem Thread ohne Meldungsqueue erledigen kann. Ein 
Presentation Manager-Programm kann große Aufgaben 
auch in einem zweiten Thread mit Meldungsqueue erledi- 
gen, der »Objektfenster« anlegt. 

Objektfenster werden in einem Thread mit Meldungs- 
queue genauso erzeugt wie normale Fenster. Sie haben eine 
Fensterprozedur, die die Meldungen an das Objektfenster 
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bearbeitet, wiederum genauso wie bei normalen Fenstern. 
Objektfenster erscheinen jedoch nicht auf dem Bildschirm 
und erhalten keine Tastatur- oder Mauseingaben. Tatsäch- 
lich erhalten Objektfenster im Prinzip nur zwei Meldungen: 
WM_CREATE und WM_DESTROY. Die Meldung WM_CREATE 
wird beim Aufruf von WinCreateWindow geschickt, der 
das Objektfenster erzeugt; WA_DESTROY wird bei dem Auf- 
ruf von WinDestroyWindow geschickt, der das Fenster 
wieder entfernt. (In der Vorabversion des Presentation 
Managers, die ich für diesen Artikel verwendet habe, erhält 
das Objektfenster parallel zum Aufruf von WinCreate- 
Window auch die Meldung WM_ADJUSTWINDOWPOS.) 

Normalerweise verwendet man Objektfenster besonders 
für den Empfang von Meldungen von anderen Fenstern, 
vielleicht, um eine objektorientierte Programmiersprache zu 
implementieren. Doch Objektfenster können auch bei der 
Bearbeitung großer Aufgaben hilfreich sein. Wenn ein 
Thread nur Objektfenster erzeugt, gibt es nur eine sehr 
beschränkte Anzahl von Meldungen, die die Fensterproze- 
dur erhalten kann. Dies vereinfacht die Bearbeitung dieser 
Meldungen in der Fensterprozedur des Objektfensters ganz 
erheblich. 

Beim Einsatz von Objektfenstern für große Aufgaben 
ergeben sich mehrere Vorteile. Das Objektfenster ist nicht 
auf eine Untermenge der Presentation Manager-Funktio- 
nen beschränkt. Sie können also für die Kommunikation 
zwischen dem Arbeitsfenster und dem Objektfenster Mel- 
dungen verwenden. Wenn Sie glauben, daß eine meldungs- 
orientierte Architektur der traditionellen Top-Down-Archi- 
tektur durchweg überlegen ist, werden sie dies vorziehen. 
Die Verwendung von Objektfenstern in getrennten Threads 
paßt besser zur Architektur des Presentation Managers als 
einfache Threads ohne Meldungsqueue. 

Die Verwendung eines Objektfensters in einem zweiten 
Thread ohne Meldungsqueue wird vom Programm BIG- 
JOBS im Listing 6 demonstriert. In der Datei BIGJOB5.C 
werden sechs Meldungen definiert, die das Arbeitsfenster 
und das Objektfenster für die gegenseitige Kommunikation 
verwenden. 

BIGJOBS legt den zweiten Thread generell nach der 
Erzeugung des Hauptfensters des Programms an. Die 
Funktion SecondThread von BIGJOBS5 sieht wie die 
main-Funktion aus. Es ruft allerdings nicht die Funktion 
WinInitialize auf, es registriert jedoch eine Fenster- 
klasse und erzeugt ein Fenster. Der Aufruf von Win- 
CreateWindow zur Erzeugung eines Objektfensters ist 
sehr einfach: Der Parameter übergeordnetes Fenster 
(parent window) wird auf HWND_OBJECT gesetzt, als zwei- 
ter Parameter wird der Name der Fensterklasse verwendet 
und alle anderen Parameter werden auf 0 oder NULL 
gesetzt. 

Wenn Sie aus dem Menü von BIGJOBS5 Start aus- 
wählen, übergibt das Arbeitsfenster die Meldung 
WM_START_CALC an das Objektfenster. Auf ähnliche Art 
wird bei der Auswahl von Abort aus dem Menü von BIG- 


MS OS/2 Presentation Manager 


JOB5 vom Arbeitsfenster die Meldung WM_ABORT_CALC 
übergeben. Beachten Sie auch, daß ClientWndProc auch 
die normale WM_CLOSE-Meldung bearbeitet (die durch 
Auswahl der Option Close aus dem Systemmenü erzeugt 
wird), indem es die Meldung WM_QUIT an das Objekt- 
fenster übergibt. 

Die Funktion ObjectWndProc beginnt mit der großen 
Aufgabe als Reaktion auf die Meldung WM_START_CALC. 
Bei der Durchführung der Berechnung kann sie nur mit 
einer von zwei Meldungen unterbrochen werden, die in 
ihrer Meldungsqueue hinterlegt werden. Dabei handelt es 
sich um WM_ABORT_CALC und WM_QUIT. In beiden Fällen 
kann die Berechnung bedingungslos abgebrochen werden. 

In der Berechnungsschleife ruft ObjectWndProc die 
Funktion WinQueryQueueStatus auf und prüft das Bit 
QS_POSTMSG des Rückgabewerts. (Es sollte eigentlich nur 
nötig sein, zu prüfen, ob der Rückgabewert ungleich Null 
ist, doch in der von mir verwendeten Vorabversion des Pre- 
sentation Managers war diese Funktion noch ein wenig 
fehlerhaft.) Diese Überprüfung von WinQueryQueue- 
Status ist fast genauso einfach wie die Überprüfung von 
bContinueCalc in BIGJOB4, doch nicht annähernd so 
kompliziert wie der Programmteil, der bei Verwendung von 
WinPeekMsg in BIGJOB3 notwendig war. 

ObjectWndProc informiert ClientWndProc darüber, 
daß es fertig ist oder abgebrochen wurde, indem es die 
Meldungen WM_CALC_DONE bzw. WM_CALC_ABORTED 
übergibt. ClientWndProc verwendet diese Meldungen 
dazu, sein Menü für weitere Berechnungen einzustellen. 

Die Beendigung des Programms auf saubere Art und 
Weise (daß heißt, sowohl der Hauptthread als auch 
SecondThread entfernen ihre eigenen Fenster und Mel- 
dungsqueues) ist knifflig. ClientWndProc bearbeitet die 
Meldung WM_CLOSE, indem es die Meldung WM_QUIT an 
das Objektfenster übergibt. Das veranlaßt ObjectWnd- 
Proc zum Abbruch der großen Aufgabe. Wenn diese 
WM_QUIT-Meldung aus der Meldungsqueue von Second- 
Thread gelesen wird, gibt WinGetMsg 0 zurück. Second- 
Thread entfernt sein Fenster sowie seine Meldungsqueue 
und übergibt die Meldung WM_OBJECT_DESTROYED an 
ClientWndProc. Bei Erhalt dieser Meldung übergibt 
ClientWndProc die Meldung WM_QUIT an sich selbst und 
beendet das Programm normal. 

Der Einsatz eines Objektfensters für große Aufgaben ist 
sicherlich komplexer als die Verwendung eines Threads 
ohne Meldungsqueue, es kann also durchaus sein, daß sie 
das nicht mögen. Darüber hinaus ist der Objektfenster- 
Ansatz nicht für alle großen Aufgaben gleich gut geeignet. 
Wenn ein zweiter Thread zum Beispiel DosRead verwen- 
den muß, um Eingaben von einer Schnittstelle zu lesen oder 
DosReadQueue, um Eingaben aus einer Queue zu lesen, 
dann wird der Thread in der OS/2-Funktion blockiert und 
kann dann natürlich den Status der Meldungsqueue nicht 
mit WinQueryQueueStatus überprüfen. 


BIGJOBS: Make-Datei 


bigjob5.obj : a Errge bigjob.h 
cl -c -FPa -G2sw -W3 -Zp bigjob5.c 


bigjob.res : bigjob.rc bigjob.h 
re -r bigjob.rc 


bigjob5.exe : bigjob5.obj bigjob5.def bigjob.res 
. link biztohe /ali " 


:16, /map, 
/nod slibe s1fbep slibfa os2, bigjob5 
rc bigjob.res bigjob5.exe 


BIGJOBS.DEF: Modul-Definitionsdatei 


BIGJOB5 
7 Ya Demo Program No. 5 (C) C. Petzold, 1988' 
182 


8192 


ClientkndProc 
ObjectWndProc 


BIGJOBS.C: Ein Objektfenster für die große Aufgabe 


#define INCL_WIN 
define INCL_DOS 


include <os2.h> 


Zinclude "bigjob.h” 


define WM_OBJECT_CREATED 
#define WMSTART_CALC 


(HMTUSER + 
(HMTUSER + 
(HMTUSER + 


OR 
#define KM_OBJECT_DESTROYED 


VOoID FAR SecondThread (VOID) ; 
ULONG EXPENTRY ObjectWndProc (HWND, USHORT, ULONG, ULONG) ; 


HWND hwndClient, Se s 
UCHAR cThreadStack [8192 


INT main (VOID) 
static CHAR szClassName [] = "BigJob5” ; 
HMQ hag ; 
HWND hwndFrane ; 
QMSG sg ; 
TID PaTkread ; 
hab = WinInitialize () ; 
hang = WinCreateNsgQueue (hab, 8) ; 


WinRegisterClass (hab, szClassName, ClientkndProc, 
CS_SIZEREDRAW, 8, NULL) ; 


hundFrame = WinCreateStdWindow (HWND DESKTOP, 
WS VISIBLE | FS_SIZEBÖRDER | FS_TITLEBAR 
I FS_SYSMENU I FS_MINMAX I FS_MENU, 
szClassName, "BigJob Demo No. 5”, 
ÖL, NULL, ID_RESÖURCE, &hwndClient) 


EnableMenultem (hwndClient, IDM_START, FALSE) ; 


if (DosCreateThread (SecondThread, &idThread, 
cThreadStack + sizeof cThreadStack)) 


Listing 6 
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WinAlarm (HWND_DESKTOP, WA_ERROR) ; 


while (WinGetMsg (hab, &qnsg, ra 8, 8)) 
WnDispatehisg (hab, &ansg) 


WinDestroykindow (hundFrame) ; 
en asih ; 
WinTerminate (hab) 


BRORR 8; 


ULONG EXPENTRY ClientWndProc (HWND hwnd, USHORT msg, ULONG mp1, 


ULONG mp2) 


{ 

static SHORT iCalcRep, iCurrentRep = ‚Im_ 18 ; 
static SHORT 1Status = STATUS_ 

static ULONG lElapsedTine ; 


eh (nsg) 
case WM _OBJECT_CREATED: 
EnableMenultem (hund, IDM_START, TRUE) ; 
break ; 


case WM COMMAND: 
BuAyen (LOUSHORT (mp1)) 


case IDM_18: 

case IDM 128: 

case IDM 1289: 

case IDM 19988: 
CheckMenultem(hwnd, ACurrentRep, FALSE); 
iCurrentRep = LOUSHORT (mp1) ; 
eg em(hund, iCurrentRep, TRUE) ; 
r 


IDM_START: 
EnableMenulten(hwnd, IDM_START, FALSE); 
EnableMenultem(hwnd, IDM_ABORT, TRUE) ; 


1Status = STATUS WORKING ; 
WinInvalidateRect (hund, NULL) ; 


ee ea 

WinPost!sg (hwndObject, WM_START_CALC, 
ie MAKEULON (iCalcRep, 2), eL): 
r ; 


IDM ABORT: 
WinPost!isg (hundObject, I_ABORT_CALG, 


Fi 
’ ’ 


EnableMenultem(hwnd, IDM_ABORT,FALSE); 
break ; 


default: 
break ; 


break ; 

case WM_CALC_DONE: 
iStatus = STATUS DONE ; 
lElapsedTime = 
WinInvalidateRe: "lan, NULL) ; 
EnableMenultem (hwnd, IDM START, TRUE) ; 
EnableMenultem (hwnd, IDM’ABORT, FALSE) ; 
break ; 

case KM_CALC_ABORTED: 


1Status = STATUS READY ; 
WinInvalidateRect (hund, NULL) ; 


Listing 6 (Fortsetzung) 
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EnableMenultem (hund, IDM_START, TRUE) ; 
break ; 


case WM_PAINT: 


Regine ‚iStatus,iCalcRep,lElapsedTime); 
reak ; 


case WM_CLOSE: 


if (hwndObject) 
WinPostNsg (hwndObject, WM_QUIT, BL, BL) ; 


lse 
WinPostNsg (hund, WM_QUIT, BL, BL) ; 
break ; 


case WM_OBJECT_DESTROYED: 


WinPostMsg (hund, WM_QUIT, BL, BL) ; 
break ; 


default: 
return WinDefWindowProc (hund, nsg, mpi, mp2) ; 


Ss DL ; 


VOID FAR SecondThread () 


Statie CHAR szClassName [] = "BigJob5.Object" ; 

QNSG qusg ; 

hmg = WinCreateMsgQueue (hab, 2) ; 

HinRegisterClass(hab, szClassName,ObjectWndProc,dL,9,NULL); 


hwndObject = WinCreatehindow (HWND_ szClassName, 
NULL, @L, 8, 8, 8, 8, NULL, ‚8, NULL, NULL) ; 


HinPostMsg (hwndClient, WM_OBJECT_CREATED, BL, BL) ; 


while (WinGet!isg (hab, &gasg, NULL, 8, 8)) 
WinDispatchiisg (hab, &gusg) ; 


KinDestroykindow (hwndobject) 5 
HinDestroyMsgQueue (hang) ; 


WinPostMsg (hundClient, WM_OBJECT_DESTROYED, AL, EL) ; 
Doskxit (6,8); 


ULONG EXPENTRY ObjectWndProc (HWND hund, USHORT msg, ULONG mp1, 


: ULONG ap2) 
double A ; 
SHORT i, iCalcRep ; 
LONG 1QueueStatus, 1Time ; 
(msg) 
case WM START_CALC: 


ne = LOUSHORT (mp1) ; 
1Time = WinGetCurrentTine (hab) - 


for hr =1.8, 1=8; 1 < iCalcRep ; i++ 


lQueueStatus = 
WinQueryQueueStatus (HWND_DESKTOP) ; 


if (1QueueStatus & QS_POSTMSG) 
break ; 


N Savage (A) ; 
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if (1QueueStatus & QS_POSTMSG) 
break ; 


lTime = WinGetCurrentTime (hab) - 1Time ; 
WinPostMsg(hwndClient, WM_CALC_DONE, 1Time, BL); 
break ; 


case WM _ABORT_CALC: 


WinPostisg(hundClient, WM_CALC.ABORTED, BL, BL); 
reak ; 


default: 
return WinDefWindowProc (hund, msg, npi, mp2) ; 


Ylsk, DL ; 
Listing 6 (Ende) 


Nie mehr »Bitte warten« 


Wir begannen damit, daß wir uns das Programm BIGJOB1 
angesehen haben, daß die ihm übertragene Aufgabe zwar 
erledigte, doch es auf eine Art und Weise tat, die für den 
Benutzer in keiner Weise vorteilhaft war. Unsere sofortige 
Ablehnung dieses Programms und unsere Suche nach bes- 
seren Wegen zur Erledigung von großen Aufgaben zeigt, 
daß wir unsere Einschätzung von einem guten Verhalten 
eines Anwendungsprogramms geändert haben. 

In einer traditionellen Singletasking-Umgebung ohne 
Fenster, muß man natürlich darauf warten, bis ein Daten- 
bankprogramm mit der Sortierung einer Datei fertig ist. 
Wenn man die Sortierung startet, ist es Zeit für eine Kaf- 
feepause. 

In einer traditionellen Multitasking-Umgebung kann es 
sein, daß das Datenbankprogramm im Hintergrund sortie- 
ren und man selbst mit einem anderen Programm arbeiten 
kann, während man darauf wartet, daß die Sortierung been- 
det wird. 

In einer Multitasking-Fensterumgebung wie dem Pre- 
sentation Manager sind wir jedoch nur dann zufrieden, 
wenn der Benutzer weiter mit dem System arbeiten kann, 
selbst wenn es große Aufgaben durchführt. Ganz klar erfor- 
dert die Komplexität der derartigen Strukturierung eines 
Programms etwas zusätzliche Arbeit vom Programmierer. 
Doch dadurch wird das Programmm besser einsetz- und 
benutzbar. 

Genauso wie wir nicht länger Programme tolerieren 
können, die vom Benutzer das Erlernen unzähliger Befehle 
erfordern, können wir es nicht länger tolerieren, daß Pro- 
gramme einfach die Meldung »Bitte warten« anzeigen und 
dann den Benutzer warten lassen, bis die große Aufgabe 
erledigt ist. 

Charles Petzold 
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SAA-Benutzeroberfläche in C 


Eine komf: 


able Benutzeroberfläche in € (Teil 1): 


Bildschirm- und Fensterverwaltung in C 


In einer Serie möchten wir Ihnen ab dieser Aus- 
gabe mehrere C-Module vorstellen, die Ihnen die 
Möglichkeit bieten, Ihre C-Programme mit einer 
SAA- bzw. DOS 4.0-konsistenten Benutzerober- 
fläche zu versehen und ein Programm dadurch 
optimal an diese neue DOS-Version anzupassen. 


Mittelfristig wird der überwiegende Teil der DOS-Anwen- 
der auf die neue Version 4.0 umsteigen und ihre integrierte 
Benutzeroberfläche zu bedienen und schätzen lernen. Mit 
dieser Oberfläche lernt der Anwender eine Bedienerfüh- 
rung kennen, die sich fortschrittlicher Interaktionsmecha- 
nismen wie Fenster, Pull-down-Menüs und File-select- 
Boxen bedient. Da liegt die Idee nahe, diese Oberfläche 
auch auf eigene Programme zu übertragen und dadurch 
nicht nur den Bedienungskomfort zu steigern, sondern 
gleichzeitig auch die Einarbeitungszeit des Anwenders zu 
minimieren. 


Konzeption der Serie 


Dieser Idee folgend wird in dieser Folge eine Bildschirm- 
und Fensterverwaltung vorgestellt, der im zweiten Teil der 
Serie ein Modul zur Maus- und Tastaturverwaltung folgt. In 
der dritten Folge wird auf der Basis dieser beiden Module 
eine Pull-down-Menüverwaltung erarbeitet, die der von 
DOS 4.0 nachgebildet ist und neben der Tastatur auch die 
Maus als vollwertiges Eingabegerät unterstützt. 

Alle Module werden unter dem Microsoft C-Compiler, 
Version 5.1, entwickelt und sind in Verbindung mit allen 
Speichermodellen dieses Compilers voll einsatzfähig. In 
jeder Folge finden Sie neben dem Source-Listing des 
eigentlichen Moduls und der zugehörigen Include-Datei 
auch ein Demo-Programm, das die Arbeit mit den einzel- 
nen Funktionen des Moduls verdeutlichen und Ihnen den 
Weg zur Einbindung dieser Funktionen in eigene Program- 
me weisen soll. 

Auch wenn Sie der Idee, eine DOS 4.0-konsistente 
Benutzeroberfläche in ihren Programmen nachzubilden, 
nicht folgen möchten, werden Sie feststellen, daß die hier 
vorgestellten Funktionen in vielen Ihrer Programme sinn- 
voll eingesetzt werden können. Neben der Steigerung des 
Bedienungskomforts bringt der Einsatz vorgefertigter 
Module auch eine nicht unwesentliche Reduzierung des 
Entwicklungsaufwandes mit sich, so daß sich das Abtippen 
(bzw. Bestellen der Begleit-Diskette) gleich in doppelter 
Hinsicht lohnt. 


Die Bildschirm- und Fensterverwaltung 


Die  Terminal-orientiertte Bildschirmausgabe über 
printf() ist schon lange »out«, die Bildschirmausgabe 
über das BIOS viel zu langsam und die Entwicklung ent- 
sprechender Assemblerroutinen nicht jedermanns Sache. 
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Bild 1: Das VIO-Modul in Aktion. 


Wie also Abhilfe schaffen, wenn auch ein noch so gutes 
Programm dem Konkurrenzdruck auf dem PC-Markt nur 
noch standhalten kann, wenn es über ein ansprechendes 
und schnelles Bildschirminterface verfügt, das sich am 
Stand der Technik - eben der »Fenstertechnik« - orientiert? 
Wer sich mit der Funktionsweise der Video-Karten des PCs 
ein wenig auskennt, dem fällt die Antwort nicht schwer: 
durch direkten Zugriff auf den Video-RAM! 

Alle Videokarten, die im PC-Bereich zum Einsatz 
kommen, von MDA und CGA bis hin zu VGA, verfügen 
über einen als »Video-RAM« bezeichneten RAM-Bereich, 
der im Textmodus die ASCII-Codes der Zeichen auf den 
einzelnen Bildschirmpositionen und ihre Farbe bzw. Attri- 
but aufnimmt. Da sich dieser RAM-Bereich, je nach der 
Art Videokarte, an der Segmentadresse 0xB000 oder 
0xB800 in den normalen PC-RAM-Speicher eingliedert, 
kann auf ihn wie auf jeden anderen Speicherbereich zuge- 
griffen werden. Ein Problem entsteht dabei nur im Fall der 
IBM-CGA-Karte, bei der der Zugriff auf den Video-RAM 
mit dem Bildschirmaufbau durch den Video-Controller syn- 
chronisiert werden muß. Unterbleibt diese Synchronisation 
entsteht eine Art »Krispeln«, das sich durch kleine weiße 
Streifen auf dem Bildschirm bemerkbar macht. 

Da sich diese Karte heute aber kaum noch im Einsatz 
befindet und die CGA-Karten anderer Hersteller dieses 
Problem nicht aufweisen, kann es bei den folgenden 
Betrachtungen vernachlässigt werden. 

Entscheidend für den Zugriff auf den Video-RAM ist 
die Kenntnis um seinen Aufbau. Hier ist zu beachten, daß 
jede Bildschirmposition innerhalb des Video-RAM zwei 
aufeinanderfolgende Speicherstellen bzw. Bytes in An- 
spruch nimmt. Das erste Byte nimmt dabei den ASCII- 
Code des Zeichens und das zweite Byte sein Attribut bzw. 
seine Farbe auf. Die Größe des Video-RAM ergibt sich 
dadurch aus der Anzahl der auf dem Bildschirm dargestell- 
ten Zeichen multipliziert mit 2. Im 80*25-Zeichen-Modus 
mit seinen 25 Bildschirmzeilen sind es 4000 Bytes, im 80*43- 
Zeichen-Modus der EGA-Karte sind es 6880 Bytes und im 
80*50-Zeichen-Modus der VGA-Karte schließlich 8000. 
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Ungeachtet der Anzahl der auf dem Bildschirm darge- 
stellten Zeilen, nimmt das Zeichen in der oberen linken 
Bildschirmecke immer die erste Position im Video-RAM, 
also die Bytes mit der Offsetadresse 0x0000 und 0x0001, ein. 
Darauf folgt das Zeichen in der zweiten Bildschirmspalte 
der ersten Zeile, das die Bytes mit den Offsetadressen 
0x0002 und 0x0003 belegt. An dieses Zeichen schließen sich 
die übrigen 78 Zeichen der ersten Zeile an, so daß diese 
Zeile die ersten 160 Bytes im Video-RAM in Anspruch 
nimmt. 

Unmittelbar auf die erste Zeile folgt im Video-RAM die 
zweite Zeile, die, wie auch alle darauffolgenden Zeilen, 
ebenfalls 160 Bytes belegt. Durch diese Anordnung der Zei- 
chen und ihrer Attribute innerhalb des Video-RAM läßt 
sich die Offsetposition eines Zeichens leicht mit Hilfe fol- 
gender Formel bestimmen: 


Offset = Spalte * 2 + Zeile * 160 


An dieser Offsetposition findet man den ASCII-Code des 
Zeichens und an der darauffolgenden Position das zugehö- 
rige Attribut- bzw. Farb-Byte. Zwar wird in dieser Formel 
von einem 80-Spalten-Bildschirm ausgegangen, doch kann 
man sie leicht an jede beliebige Bildschirmauflösung anpas- 
sen, indem man die Konstanten 160 durch den Ausdruck 


(Anzahl der Spalten pro Zeile * 2) 


ersetzt. 

Das Verständnis dieses Aufbaus allein reicht aus, um 
den theoretischen Hintergrund der einzelnen Funktionen 
aus dem hier vorgestellten Modul zu verstehen. 


Das C-Modul VIO.C 


Alle Funktionen des Moduls zur Bildschirm- und Fenster- 
verwaltung befinden sich innerhalb der Datei VIO.C 
(Listing 2). Um die Funktionen dieses Moduls innerhalb 
Ihrer Programme aufrufen zu können, müssen zwei Schritte 
vollzogen werden: Ähnlich wie bei den Funktionen aus der 
Bibliothek Ihres Microsoft C-Compilers, sollten Sie 
zunächst die Datei VIO.H (Listing I) über den #include- 
Befehl in Ihr C-Programm einbinden. In ihr befinden sich 
die Deklarationen der einzelnen Funktionen aus dem VIO- 
Modul sowie eine ganze Reihe von Typ-, Konstanten- und 
Makrodefinitionen, die Sie zum Aufruf der einzelnen Funk- 
tionen benötigen. 

Beim Aufruf des Compilers zur Kompilierung Ihres Pro- 
gramms müssen Sie dann neben dem Namen Ihres Pro- 
gramms auch den Namen des VIO-Moduls angeben, damit 
dieses ebenfalls kompiliert und während des Link-Vorgangs 
mit Ihrem Programm verbunden wird. 

Eine zentrale Rolle kommt innerhalb dieses Moduls den 
Strukturen windes, velb und velw zu, wobei letztere in 
der Include-Datei VIO.H definiert und dort zu der Union 
vel zusammengeschlossen werden. Vel steht dabei für 
»Video-ELement« und beschreibt die Darstellung einer 


Include-Datei 


zur Einbindung : der Funktionen zur Bildschirn- 


| 
erstellt am : 23.11.198| 
letztes Update am: 6.12.1988 


(Copyright) : 1988 by MICHAEL TISCHER 


/* wir basteln uns ein BYTE */ 
/* dito: WORD %*/ 
/* nur als Abk hraing “/ 


/#-- Strukturen 
struct velb { /* eine Bildschirmposition als 2 Bytes */ 
BYTE zeichen, /* der ASCII-Code */ 

attribut; /* das zugehörige Attribut #/ 


struct velw { /* eine Bildschirmposition als 1 Word */ 
1%; 


/* ASCII-Zeichen und Attribut */ 

/#* beschreibt eine Bildschirmposition */ 
struct velb h; 
struct velw x; 


union vel { 


/*-- Konstanten 
#define TRUE 1 
#define FALSE 8 


define SCHWARZ 
#define BLAU 
#define GRUEN 
#define CYAN 
#define ROT 
#define VIOLETT 
define BRAUN 
define DGRAU 
define HGRAU 
#define HBLAU 
#define HGRUEN 


/* Farben für Color-Karten 


DOSJnNV > —n 


#define BLINKEN 128 


08x87 /* Attribute für Mono-Karten 
Bxdf /* besonders helle Schrift */ 
78 /* schwarz auf weiß */ 
8x81 /* unterstrichenes normales Zeichen */ 
2xBB /* schwarz auf schwarz */ 
#define IUNVISI 8x77 /* weiß auf weiß %*/ 
define EINRA 


/* Rahmentypen für VioFrame */ 

1 
2 
3 

define KEINRA Bxff 


#define NOCLEAR Bxff 


/* keinen Rahmen ziehen */ 


/* kein Löschen der Leerzeilen */ 
/* bei den Scroll-Funktionen */ 


/*-- Codes für die verschiedenen Videokarten 
define MDA 
#define CGA 
#define EGA 
#define EGA_MONO 
#define VGA” 
define VGA_MONO 
#define MCGA 
#define MCGA_MONO 7 


/%* MDA und HGC Y 


/* EGA an MDA-Monitor */ 


/* VGA an analogem Mono-Monitor */ 


av >»Wv on 


/* MCGA an analogem Mono-Monitor */ 


Listing 1: VIO.H 
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/%®-- Macros 


#define COL( 


v‚h)t(h) «4 l m ) /% definiert Farbbyte */ 
LINKEN ) 


#define BLINK(c)((c)! B 

#define : yl, x2, y2) \ 

#define AKTZ ( vzeile ) 
lte ) 

(( 1) + viewx1) /* linke Deha in View-Ber. * 

) + viewy1) /* obere 

{ 


Jdefine AKTS ( 


Zdefine VL(i 
#define VO(i 


#define VCOL ( viewx2 - viewi +1) /*S 
#define VROW ( viewy2 - viewyl +1) /%* 


((x2)- KDD * ((y2)-(y1)+1) * sizeof( VEL ) ) 
/* die aktuelle Zeile */ 
/* die aktuelle Spalte 7 


ile in View-Ber. 
i ) + viewx2) /* rechte Spalte im Viev-B. 

( 1 ) + viewy2) /* untere Zeile im View-Ber. 
lten im Viev-B. 
eilen im Viev-B. 


/#-- Funktionsdeklarationen über Makros 


define VioClear(x1,y1,x2,y2,f) 


VioFill(x1,y1,x2,y2,' ',f) 


#define VioClearScreen( f ) \ 


vi 


#define VioScrollLeft(x1, 


vi 


#define VioScrollRi 


vi 


#define VioGetS:; 


define Viol 


oFill(8 ‚ö , anzcol-1, anzline-1, ’ ’, f) 
yl, x2, 2 anz, £)\ 

oScrollHori( x1, yl, y2, anz, f, TRUE ); 

t(x1, yl, x2, y2, anz, DV 

oScrollHori( x1, y1, x2, y2, anz, f, FALSE ); 

ten() ( vkarte ) 

sColor() ( color ) 


#define VioSetLines(x) ( anzline = (x) ) 
#define VioGetLines() ( anzline ) 
#define VioSetCols(x) ( anzcol = (x) ) 


#define VioGetCols() 


( anzcol ) 


#define VioHideCursor() VioSetCursor( 8, anzline ) 


/#-- externe 
extern BYTE 


Variablen 


viewx1, /%* obere linke Ecke des View-Bereich */ 
viewy!, _/®* in Bezug auf den ganzen Bildschirm */ 
viewx2, /* untere rechete Ecke des View-Bereich %*/ 
vn /* in Bezug auf den ganzen Bildschirn */ 

‚ /% die aktuelle Cursorposition in *%/ 
vspalte, /* Bezug auf den gesamten Bildschirm */ 
vkarte, /* Code für die aktive Video-Karte */ 
color, /* TRUE, wenn Farbdarstellung */ 
anzline, /* Anzahl der Bildschirmzeilen */ 
anzcol; /* Anzahl der Bildschirmspalten */ 


/%*-- Funktions-Deklarationen 


void Violnit 
void VioSetView 
void VioGetView 


void VioGet 
void VioPut 
BYTE VioWi 


( void ); 

( BYTE x1, BYTE y1, BYTE x2, 

( BYTE * x1, BYTE * y1, 
BYTE * x2, BYTE * y2 ); 

( BYTE x1, BYTE y1, BYTE x2, 


n « BYTE x1, BYTE yl, B 


void VioWinClose ( BYTE redraw ); 

void VioSetCursor ( BYTE spalte, BYTE zeile ); 
BYTE VioGetCurCol ( void ); 

BYTE VioGetCurRow ( void ); 


void VioPrint 


void VioPrin 


char *VioStrep 


void VioFill 


void VioFrame 


void VioScro 


void VioScro 


BYTE VioMoveUp 


( BYTE spalte, BYTE zeile, BYTE farbe, 
BYTE cursor, char * string ); 
tf _d( BYTE spalte, BYTE zeile, BYTE farbe, 
BYTE cursor, char * string, ... ); 
( char zeichen, BYTE anz ); 
( BYTE x1, BYTE y1, BYTE x2, 
char zeichen, BYTE farbe); 
BYTE y1, BYTE x2, 
y2, BYTE rahmen, BYTE farbe ); 
11lp ( a x1, 


y2, BYTE anzahl, BYTE farbe Er 
11Down( BYTE x1, BYTE y1, BYTE x2, 

BYTE y2, BYTE anzahl, BYTE farbe % 
( BYTE anzahl ); 


BYTE VioMoveDown ( BYTE anzahl ); 


BYTE VioMoveRight ( BYTE anzahl ); 
( BYTE anzahl ); 
r ( BYTE x1, BYTE y1, BYTE x2, 


BYTE y2, BYTE farbe ); 


BYTE VioMoveLe 


void VioColo: 


Listing 1: (Ende) 
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Bildschirmposition innerhalb des Video-RAM. Während 
velw die beiden Bytes, die eine Bildschirmposition reprä- 
sentieren, unter dem Namen inhalte zu einem Wort 
zusammenfaßt, können der ASCII-Code des Zeichens und 
sein Attribut-Byte mit Hilfe der Struktur velb individuell 
über die Variablen zeichen und attribut angesprochen 
werden. 

Indem der Video-RAM als ein Vektor, bestehend aus 
Elementen vom Typ der Union vel, betrachtet wird, kann 
auf alle Zeichen individuell zugegriffen werden. Wichtig ist 
dabei allerdings, daß der Zugriff jeweils über Pointer 
geschieht, da dieser Vektor (der Video-RAM) nicht zu den 
Daten des C-Programms zählt, sondern fest im Speicher 
lokalisiert ist. Pointer, die dem Zugriff auf diesen Vektor 
dienen, müssen grundsätzlich vom Typ far sein, da sich der 
Video-RAM außerhalb des Datensegments des C-Pro- 
gramms befindet. Ein entsprechender Variablentyp wird 
innerhalb des VIO-Moduls mit Hilfe des typedef-Befehls 
in Form des Variablentyps vpfar (Viodeo-Pointer far) 
definiert. 

Die Adresse einer Bildschirmposition kann einem Poin- 
ter vom Typ vpfar mit Hilfe des Makros vpos zugewiesen 
werden. Er bezieht die Segmentadresse des Video-RAM 
aus der globalen Variablen vstart, zu der er die Offset- 
adresse des Zeichens addiert. Sie erhält er durch das Makro 
vofs, in dem sich der Aufbau des Video-RAM widerspie- 
gelt. 

Hat man mit Hilfe des Makros vpos einen Pointer auf 
die entsprechende Bildschirmposition gesetzt, kann auf 
diese Bildschirmposition über die Komponenten der Union 
vel, die Strukturen velw (mit dem Namen x) und velb 
(mit dem Namen h), und deren Komponenten zugegriffen 
werden. Die folgende Codesequenz bringt z.B. den Buch- 
staben A an die Bildschirmspalte 10 der Zeile 2, wobei der 
Buchstabe mit grüner Farbe auf schwarzem Grund 
(Farbcode = 2) erscheint. 


{ 
VPFAR vptr; 


vptr = VPOS( 19, 2 ); 
vptr->h.zeichen = ’A’; 
vptr->h.attribut = 5; 
) 


Etwas beschleunigen kann man den Zugriff auf die Bild- 
schirmposition zusätzlich dadurch, daß man das Zeichen 
und das Attribut gleichzeitig über die Struktur velw als 
Wort in die entsprechende Speicherstelle innerhalb des 
Video-RAM lädt: 
vptr->x.inhalt = ’A’ + (5 «<< 8); 

Für die Fensterverwaltung innerhalb des Moduls spielt 
die Struktur windes eine große Rolle. Immer, wenn ein 
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Fenster auf dem Bildschirm geöffnet wird, wird eine solche 
Struktur für das neue Fenster angelegt und an das Ende des 
Fenster-Vektors angehängt. Dieser Vektor, der dynamisch 
auf dem Heap allokiert wird und dessen Adresse in der glo- 
balen Variablen winptr verzeichnet ist, enthält für jedes 
der geöffneten Fenster einen Eintrag vom Typ der Struktur 
windes. Indem Fenster nach dem LIFO-Prinzip geöffnet 
und wieder geschlossen werden, vergrößert und verkleinert 
sich dieser Vektor dynamisch. Die maximale Anzahl der 
gleichzeitig geöffneten Fenster wird dabei nur durch die 
Größe des freien Speicherplatzes auf dem Heap beschränkt, 
der neben dem Fenster-Vektor auch jeweils einen Puffer 
aufnehmen muß, in dem der Bildschirminhalt unter dem 
Fenster gespeichert wird. 

Neben der Adresse dieses Puffers finden sich innerhalb 
der Struktur windes auch die Eckkoordinaten des Fensters 
sowie die aktuelle Cursorposition zum Zeitpunkt, an dem 
das Fenster geöffnet wurde. Darüberhinaus werden hier 
auch die Koordinaten des View-Bereichs gespeichert, von 
dem später noch die Rede sein soll. 


Die Funktionen des VIO-Moduls 


Nach diesem Einblick in die Art, wie innerhalb des VIO- 
Moduls auf den Bildschirm zugegriffen und die einzelnen 
Fenster verwaltet werden, geben die folgenden Seiten einen 
Überblick über die einzelnen Funktionen, die das VIO- 
Modul dem Aufrufer bereitstellt. Die Funktionen werden 
dabei in der Reihenfolge ihres Auftretens innerhalb des 
Listings vorgestellt. Während hier allerdings nur die grund- 
sätzliche Aufgabe der einzelnen Funktionen vorgestellt 
werden kann, können Sie die jeweils zu übergebenden Para- 
meter und ihre Reihenfolge der Include-Datei VIO.H bzw. 
dem VIO-Modul VIO.C entnehmen. 


Violnit 

Als erste Funktion aus diesem Modul muß immer die 
Funktion VioInit aufgerufen werden, die das Modul 
initialisiert. Sie stellt zunächst die Art der aktiven Video- 
karte fest und speichert einen entsprechenden Code, wie er 
in den Konstanten CGA, MDA etc. innerhalb der Datei 
VIO.H verzeichnet ist, in der globalen Variablen vkarte 
ab. Innerhalb des Anwendungsprogramms kann er mit Hilfe 
des Makros VioGetSys (ebenfalls VIO.H) abgefragt wer- 
den. Auf der Basis dieser Information lädt VioInit dann 
die Segmentadresse des Video-RAM in die globale Varia- 
ble vstart. 

Darüber hinaus setzt sie das color-Flag, das anzeigt, 
ob die Videokarte Farben oder nur Schwarz-Weiß-Attri- 
bute anzeigen kann. Dieses Flag kann durch das Makro 
ViolsColor abgefragt werden. Es liefert den Wert 
ungleich 0 zurück, wenn die Karte Farben darstellen kann. 
Bei einer monochromen Bildschirmkarte wird dem Aufru- 
fer hingegen der Wert 0 zurückgeliefert. 


Damit das VIO-Modul auch mit den neuen Bildschirm- 
auflösungen der EGA- und VGA-Karten einwandfrei 
zusammenarbeiten kann, ermittelt es zusätzlich die Anzahl 
der Zeilen und Spalten auf dem Bildschirm und trägt sie in 
die Variablen anzline (Anzahl der Zeilen) und anzcol 
(Anzahl der Spalten) ein. Über die Makros VioGetLines 
und VioGetCols können Sie den Inhalt dieser Variablen 
innerhalb Ihrer Anwendungsprogramme jederzeit abfragen. 
Umgekehrt können Sie den Inhalt dieser Variablen über die 
Makros VioSetLines und VioSetCols ändern. Dies 
sollte immer dann geschehen, wenn Sie die Anzahl der 
Zeilen und Spalten auf dem Bildschirm verändern, da ein- 
wandfreie Arbeit des VIO-Moduls von der genauen Kennt- 
nis der Bildschirmauflösung abhängig ist. 


VioSetView 

Diese Funktion definiert den aktuellen View-Bereich, 
bei dem es sich um einen Bildschirmbereich handelt, der 
vor allem in Verbindung mit Fenstern zum Einsatz kommt. 
Er erlaubt die Bezugnahme auf die Eckkoordinaten des 
aktuellen Fensters anstelle absoluter Bildschirmkoordina- 
ten. Dies ist vor allem dann von Vorteil, wenn ein Fenster 
über den Bildschirm verschoben wird und seine Bildschirm- 
position damit nicht konstant ist. 

Zwar erwarten alle Funktionen innerhalb des VIO- 
Moduls Koordinaten, die sich auf den gesamten Bildschirm 
beziehen, doch kann mit Hilfe der Makros vl, vo, vr und 
vu aus der Datei VIO.H auf die Eckkoordinaten des aktu- 
ellen View-Bereichs Bezug genommen werden. Zusätzlich 
kann die Spaltenbreite des jeweils aktuellen View-Bereichs 
mit Hilfe des Makros vcol und die Anzahl der Zeilen 
innerhalb des View-Bereichs durch das Makro vrow ermit- 
telt werden. 

Während VioInit den gesamten Bildschirm als View- 
Bereich deklariert, wird beim Öffnen eines Fensters der 
View-Bereich mit dem Bildschirmbereich gleichgesetzt, 
über den sich das Fenster erstreckt. 

Eine anderer View-Bereich kann jeweils durch den Auf- 
ruf der Funktion VioSetView definiert werden. 


VioGetView 

Im Gegensatz zu VioSetView ermittelt VioGetView 
die Eckkoordinaten des aktuellen View-Bereichs und über- 
gibt sie dem Aufrufer in den Variablen, deren Adresse er 
beim Aufruf von VioGetView angegeben hat. 


VioGet 

Der Inhalt eines Bildschirmbereichs (die Zeichen und 
ihre Attribute) kann mit Hilfe von VioGet in einen Puffer 
geholt werden, dessen Adresse VioGet als Far-Pointer 
übergeben wird. Die Größe des Puffers kann der Aufrufer 
mit Hilfe des Makros buflen ermitteln, das in der Datei 
VIO.H definiert wird. 
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: Stellt verschiedene Funktionen zum 
Zugriff auf den Bildschira bereit. 


: MICHAEL TISCHER 
entwickelt am : 23.11.1988 
letztes Update : 6.12.1988 


ee ee 
» CL /ALSIMICILIH) VIO.C /C / 
dann mit einem anderen Modul linken 


/* Erstellung 
/# 

/ 

/#-- Include-Dateien einbinden ----------------------------- #/ 
#include "vio.h” 


/pragma pack(1) 
/#-- Typedefs 


typedef VEL far * VPFAR; /* FAR-Pointer in den Video-RAM */ 
typedef struct windes WINDES; /* ein Fensterbeschreiber */ 
typedef WINDES * WIPTR; /%* Pointer auf Fensterbeschreiber */ 


#define MK_FP(seg,ofs) ((void far *)\ 
((unsigned u ) << 16) I (ofs))) 
#define VOFS(x,y) ( anzcol *(y)+(x) s 
#define VPOS(x,y) (VPFAR) ( vstart + Vors! 3 A An, 
#define WINDESLEN ( sizeof(struct windes) ) 
#define VELLEN ( sizeof( VEL ) ) 


#ifdef M_I86SM /* wird im SMALL-Modell ko 
#define NEARDATA /* Ja, 

Fendif 

#ifdef M_I86MM /* wird im MEDIUM-Modell k 
#define NEARDATA /* Ja, 

Fendif 


Zifdef NEARDATA /* NEAR-Daten? */ 
#define MOVE(s, d, 1) movedata( = SEG( (void far *) s ), \ 
OFF( (void far *) s ), N 
PP- SEG( (void far *) d), 
ER OFF( (void far *%) d ), N 
) 
delse /* Nein, FAR-Daten */ 
#define MOVE(s, d, 1) \ 
memmove( (void far *) d, (void far *) s, 1) 
#endif 


/#=-- Strukturen 


struct windes { 
BYTE x1, y1, 
x2, y2, 
viewx1, viewyl, 
viewx2, viewy2, 
curs, curz; 
VEL * winmen; 


iliert? %#/ 
-Daten */ 


iliert? ®/ 
-Daten */ 


/* Fensterbeschreiber */ 
/* die Eckkoordinaten des Fensters */ 


/* Koordinaten des View-Bereich #/ 


/* Cursorkoordinaten vor Öffnen */ 
/%* Pointer auf Fenster-Puffer */ 


} 
/*-- globale Variablen 


VPFAR vstart; /* Pointer auf das erste Zeichen im Video-RAM #*/ 
BYTE vzeile, /* nimmt die aktuelle Cursorposition auf */ 
vspalte, 
viewxi, /* obere linke Ecke des View-Bereich */ 
viewyl, /®* in Bezug auf den ganzen Bildschirm */ 
viewx2, /* untere rechte Ecke des View-Bereich */ 


Listing 2: VIO.C 
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en: /* in Bezug auf den ganzen Bildschirm */ 
vkar /* Code für die aktive Videokarte */ 
berpan "a ist TRUE, wenn Video-Karte Farben darstellt */ 
anzline = 25, /* Anzahl der Bildschirmzeilen */ 
/* Anzahl der Bildschirmspalten */ 

n=ß; /* Anzahl der geöffneten Fenster */ 

s /* Ptr auf Fensterbeschreiber */ 


s gexket die Arbeit mit dem VIO-Modul 
ein. 
: keine 
: keiner 
: Diese Funktion mup als erste Funktion 
aus diesem Modul aufgerufen werden. 
REINE NE HEINE NENNE IE NENNE NEE EEE EEE BEENDEN EEE NEE EEE NEE EEE EEE EEE, 


pn Violnit( void ) 


static BYTE vmodel] = { 
MDA, CGA, 8, EGA, EGA_MONO, 8, 
ar: VGA, 8, MCGA, MCGA_MONO, 


3; 
static BYTE egamode[] = { 
EGA, EGA, EGA_MONO, 


union REGS regs; /* Prozessorregs für Interruptaufruf */ 
vkarte = Bxff; /* noch keine Video-Karte entdeckt */ 


es testen, Kr) VGA- oder MCGA-Karte installiert ist 
vn .X.ax = Bxladd; /* Funktion 1Ah des Video- */ 
86(Bxid, &regs, &regs); /%* BIOS aufrufen “/ 
ir ( regs.h.al == fxla ) /®* VGA oder MCGA? */ 
/* Ja */ 
vkarte = vmodel regs.h.bl-1 ]};  /* Code aus Tab. holen */ 
color = f( vkarte==MDA || vkarte=-EGA_ MONO ); 


else /* weder VGA noch MCGA */ 
{ /%* auf EGA-Karte testen */ 
re s.h.ah = &x12; /* Funktion 12h Unterfunktion */ 
reg .h.bl = PSCH “/ 


/* 18h aufrufen 
86(Bxid, iregs, &regs); /* Video-BIOS aufrufen */ 
ir ( regs.h.bl 


Bx1d ) /® EGA installiert? */ 

/" Ja %/ 
vkarte = egamode[ (regs.h.cl >> 1) % 3 ]; /* hole Code */ 
ni = ( vkartet!=EGA_MONO ); 


} 


I Aa auf Video-RAM ermitteln / 
regs.h.ah = 15; /* aktuellen Video-Modus ermitteln */ 
int86(Bx1B, Pe &regs); /* BIOS-Video- Interrupt aufr. */ 
vstart = (VPFAR HK FP((regs.h. ... ? Bxbedh : AxbBdd, B); 
if ( vkarte == Bxff) /* weder EGA, VGA oder MCGA? #/ 
vkarte = oleretres s.h.alt=7)) ? CGA : MDA; /* Ja */ 
else /* ist EGA, VGA oder MCGA, Zeilen ermitteln */ 
anzline = *((BYTE far *) MK_FP( Bx4d, Bx84 )) + 1; 
if ( regs.h.al==8 || regs.h.al==2 ) 
color = FALSE; /* in Color-Modus ohne Farbdarstellung */ 


anzcol = *((BYTE far *) MK_FP( Bx4B, Bxda )); /%* Spalten */ 
ig h.ah = 5; /* aktuelle Bildschirmseite auswählen */ 
: .h.al = ß; /* Bildschirnseite 8 */ 
86(Bx1d, &regs, &regs); /* BIOS-Video-Int. aufrufen */ 


/* aktuelle Cursorposition ermitteln */ 
iff auf die Bildschirnseite ® */ 
/* BIOS-Video-Int. aufrufen */ 
/* Gursorposition merken #/ 


da h.ah = 3; 
nen .h.bh = 8; /* Zugr 
86(Bx1d, aregs, &regs); 

En = regs.h.dh; 

vspalte = regs.h. di; 

VioSetView(ß, 8, anzcol-1, anzline-1); /* View-B. =ges. Bs. */ 

Re = (WIPTR) malloc( 1 ); /* ein Byte für Fensterbes. */ 


Listing 2: (Fortsetzung) 


SAA-Benutzeroberfläche in C 


: Setzt einen neuen View-Bereich 
* Eingabe-Parameter: X1, Yi = obere linke Ecke des Bereichs * 
* %2, Y2 = untere rechte Ecke des Ber. * 


* Return-kert : keiner * 
EEE NEBENEINANDER / 


= VioSetView( BYTE x1, BYTE y1, BYTE x2, BYTE y2 ) 


viewxl = x1; 
viewy! = yl; 
viewx2 = x2; 
ame = y2; 


/* Koordinaten in den globalen */ 
/* View-Variablen merken ”/ 


BERNIE NIE NEBEN IE DEE EHE DENE DE DE DEE IE DE DENE ENDE EEE EINE DE NENNE NENNE NENNE NEIN 
:VioGetView 


: Holt die Koordinaten des aktuellen 
View-Bereichs. 
Eingabe-Parameter: X1, Y1 = Pointer auf Variablen, die 
x2, Y2 die Koordinaten des View- 
Bereichs aufnehmen. 


4 


Sue xx 


Return-Wert : keiner 
DEN DD EB EEE EEE EEE EEE NENNEN NENNE NENNEN NEUE IE NENNE 


Ya VioGetView( BYTE * x1, BYTE * yl, BYTE * x2, BYTE * y2 ) 


/* Koordinaten aus den globalen */ 
/* View-Variablen holen “/ 


: Holt einen Bildschirmbereich in einen * 
Puffer. * 
Eingabe-Parameter: X1, Yi = obere linke Ecke des Bereichs * 
X2, Y2 = untere rechte Ecke des Ber. * 
BPTR = Pointer auf Anfang des Puffer * 
Return-Wert : keiner * 
Info : Der Aufrufer ist dafür verantwortlich, * 
daß die Größe des übergebenen Puffers * 
zur Speicherung des Bereichs ee, 
HE NENEIENE NENNEN IE EEE NEE EEE ENDEN 


** 
* 
%* 
* 
* 
* 
%* 
%* 
%* 
* 


III NENNEN NENNEN NENENENIENEIEIEIEIEE: 


void VioGet( BYTE x1, BYTE y1, BYTE x2, 
i BYTE y2, VEL far * bptr ) 


int nbytes; /* zu kopierende Bytes pro Zeile */ 
VPFAR vioptr; /%* Pointer in den Video-RAM */ 
unsigned temp; 


nbytes = ( x2 - xi1 + 1 ) * VELLEN; /* Bytes pro Zeile */ 
for ( ; yl <= y2; +yl ) /* die Zeilen durchlaufen */ 
{ /* jeweils eine Zeile in den Puffer holen */ 
vioptr = VPOS(x1, yl); /* Pointer auf 1. Byte in Zeile */ 
( vioptr, bptr, nbytes); 
re far *) bptr += nbytes; 


EEE 
* Funktion W740, Put 
*r 


: Kopiert den Inhalt eines Puffers in 
einen Bildschirmbereich. * 
X1, Yi = obere linke Ecke des Bereichs * 
X2, Y2 = untere rechte Ecke des Ber. * 
BPTR = Pointer auf Anfang des Puffer * 

* 


Return-Wert : keiner 
REINE NEIEIE HEINE NENNEN NENNEN NIE ED NENNE NENNEN EEE NENNE / 


Listing 2: (Fortsetzung) 
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void VioPut( BYTE x1, BYTE y1, BYTE x2, 
BYTE y2, VEL far * bptr ) 


{ 

int nbytes; /* zu kopierende Bytes pro Zeile */ 
VPFAR  vioptr; /* Pointer in den Video-RAM %*/ 
unsigned tenp; 


nbytes = ( x2 - x! + 1 ) * VELLEN; /* Bytes pro Zeile */ 
for ( ; yl <= y2; ++y1 ) /* die Zeilen durchlaufen %/ 
ee eine Zeile in den Video-RAM kopieren */ 


{ 
vioptr = (x1, yl);  /* Pointer auf 1. Byte in Zeile */ 


( bptr, vioptr, nbytes); 
Kin Ir *) bpt. % 


r += nbytes; 


HINEIN III 
:VioWinOpen 


: Öffnet ein Bildschirmfenster und 
sichert den Inhalt des darunter- 
liegenden Bildschirmbereichs. 

Eingabe-Parameter: X1, Yi = obere linke Ecke des Bereichs * 
X2, Y2 = untere rechte Ecke des Ber. * 
Return-kert : TRUE, wenn das Fenster geöffnet werden * 
konnte, sonst FALSE * 
RENNEN NN / 


ze x* 


Pi VioWinOpen( BYTE x1, BYTE y1, BYTE x2, BYTE y2 ) 


VEL * bptr; /* Ptr. auf Puffer mit Bildschirminhalts 
WIPTR wptr; /* Pointer auf Vektor mit Fensterbeschreibern 


if ( (bptr = (VEL *) malloc(BUFLEN( x1, yl, x2, y2 ))) ) 

{ /%* es konnte ein Puffer allokiert werden 
wptr = (WIPTR) realloc(winptr, WINDESLEN * (winopen+1)); 
1 ( wptr ) /* konnte der Vektor vergrößert en 

* Ja 
winptr = wptr; /* die neue Adresse des Vektors merken 

(wptr += winopen)->x1 = x1; /* die Koordinaten 

-)x2 = x2; /* des Fensters in 
wptr->yl = yl; /* Fensterbeschr. 
wptr->y2 = y2; /* nerken 
wptr->curs = vspalte; /* die aktuelle Cursorposition 
wptr->curz = vzeile; /* ebenfalls speichern 
wptr->viewxi = viewxl; /* die Koordinaten des 
wptr->viewyl = viewyl; /* View-Breiches im 
wptr->viewx2 = viewx2; /* Fensterbeschreiber 
wptr->viewy2 = viewy2; /* speichern 
VioSetView( x1, yl, x2, y2 ); /* neuer View-Bereich 
VioGet( x1, yl, x2, y2, re = bptr ); 
++winopen; /* Anzahl Fenster inkrementieren 
return TRUE; /* Fenster konnte geöffnet werden 


else /* der Vektor konnte nicht vergrößert werden 


free( bptr ); 


/* Bildschirmpuffer wieder freig. 
er ALSE; 


/* sit Fehler zurück 


} 
else /* es konnte kein Puffer allokiert werden 
return FALSE; 


] Pa EEE N BENENNEN NEBEN 
:VliloWincClose 


: Schliept das zuletzt geöffnete Fenster 
wieder. 
REDRAK = TRUE: der Bildschirminhalt 
unter dem Fenster wird 
zurückkopiert. 


Listing 2: (Fortsetzung) 


SAA-Benutzeroberfläche in C 


void VioWinClose( BYTE redraw ) 


WIPTR wptr; /* Pointer auf Vektor mit den Fenster-Beschr. 
union vel * buptr; /* Pointer auf Puffer für das Fenster 
B /* Schleifenzähler 
/* Koordinaten des Fensters 


yi, y2, xt; 
/* Pointer in den Video-RAM */ 


VPFAR video; 


/* ist überhaupt ein Fenster geöffnet? */ 
/* Ja #/ 
wptr = winptr + winopen - 1; /%* Ptr auf Fensterbeschr. 
if ( redraw ) /* alten Fensterinhalt zurückkopieren? 
{ /* Ja, aus Puffer in Video-RAM kopieren 
VioPut( wptr->x1, wptr->yl, wptr->x2, 
wptr->y2, wptr->winnen ); 
VioSetView( wptr->viewxi, wptr->viewyl, wptr->viewx2, 
wptr->viewy2 ); /* View-Bereich zurück 
een wptr->curs, wptr->curz ); /* Cursor 


2 (winopen) 


free( (void *) wptr->winmem ); /* Fenstersp. freigeben 
/*-- den Vektor mit den Fensterbeschr. verkleinern 
‚ers = (WIPTR) realloc(winptr, WINDESLEN*(--winopen)+1); 


} 


LE ET 
:VioSetCursor 


: Setzt den blinkenden Bildschirmcursor 
und die interne Ausgabeposition. 
SPALTE = die neue Cursorposition 
ZEILE 
Return-kert : keiner 
Info E 


nn VioSetCursor( BYTE spalte, BYTE zeile ) 
union REGS regs; 


regs.h.ah = 2; 
regs.h.bh = 8; 
regs.h.dh = vzeile = zeile; 
regs.h.dl = vspalte = spalte; /* Spalte merken */ 
a 86(Bx1d, Aregs, &regs); /%* BIOS-Video-Intr. aufrufen %*/ 


/* Prozessorregs. für Interruptaufruf %*/ 


/* Funktionsnummer für Set Cursor #/ 
/* auf die Bildschirmseite 8 zugreifen */ 
/* Zeile merken */ 


Een 
:VioPrint 


: Schreibt einen String direkt in den 
Video-RAM. 
Eingabe-Parameter: zu: = die Ausgabeposition 
E 


FARBE = das Attribut für die Zeichen 
CURSOR = TRUE, wenn der Cursor hinter 
die Ausgabe gesetzt wird 
STRING = Pointer auf den String 
Return-kert ; keiner 
Info Rn u String wird unforsatiert ausge- 
eben. 


Aufgabe 


-EKKKEKEKKK K 
Se ‚Ze Ze Ze Ze 22 ze 22 22 ze u; 


| 
| 


void VioPrint( BYTE spalte, BYTE zeile, BYTE farbe, 
BYTE cursor, char * string ) 


{ 
Sa VPFAR Iptr; /* Laufzeiger zum Schreiben des Str. */ 
n 


neupos; /* Cursorposition als Offset */ 
ae + zeile * anzcol; 

(spalte, zeile); /* Pointer in Video-RAM setzen */ 
/* String durchl. #/ 


lptr->h.zeichen = #*(string++); /* Zeichen in VIDEO-RAM */ 
ea = farbe; /* Attribut des Zeichen setzen */ 


” ( ; *string ; ++neupos, ++lptr) 


Listing 2: (Fortsetzung) 


if ( cursor ) /* Cursor hinter die Ausgabe setzen? */ 
VioSetCursor( neupos % anzcol , neupos / anzcol ); /* Ja */ 


JR WERIENEBIENENE NEN NENNE NEN NN N N NN N 
* Funktion : VL OrPIFI nt 


: Formatiert einen String wie bei PRINTF * 
und schreibt ihn dann direkt in den 
Video-RAM. 
Eingabe-Parameter: ee = die Ausgabeposition 
FARBE = das Attribut für die Zeichen 
CURSOR = TRUE, wenn der Cursor hinter 
die Ausgabe gesetzt wird 
STRING = Pointer auf den String 
ie = weitere Argumente 
Return-kert : keiner 
Info : = Der String kann die Formatkenn- 
zeichen wie bei PRINTF enthalten. 
- Der Cursor wird nach der Ausgabe 
hinter das letzte Zeichen gesetzt. 
Ba a 2 20502 212.208 .2 20202027272 .2.202.272.21202.2.2.2.2.2.2.202 02020202 72.202.2.20202.2.502.202020202020202.202.2.2.2.7 


KEKKKEKKEKEKKE EEE * x 


SEE KK E KK E E * 


void VioPrintf( BYTE spalte, BYTE zeile, BYTE farbe, 
BYTE cursor, char * string, ... ) 


{ 

va_list parameter; 
char ausgabe[255]; 
int neupos; 


/* Paraneter-Liste für VA_... Macros */ 
/* Puffer für formatierten String */ 
/* neu Cursorposition als Offset */ 


va_start( parameter, string ); /* Parameter umwandeln */ 
vsprintf( ausgabe, string, parameter ); /* formatieren */ 
VioPrint( spalte, zeile, farbe, cursor, ausgabe ); 


[HEHE HEBEN EEE NEN NENNE N NE EEE 
:VioStrep 


: Baut einen String aus einem einheit- 
lichen Zeichen auf. 
Eingabe-Parameter: ASCII = Das Zeichen 
ANZ = Anzahl der Wiederholungen 
Return-kert : Pointer auf den erstellten Str Ki 
Info : = ANZAHL darf nicht größer als 132 
sein. 
- Der String "lebt” nur bis zum 
nächsten Aufruf von VioStrep. 
UI HEN DENE EHE DE BE DENE EEE DE DD D D EE 


Aufgabe 


EEE 


* 
* 
”* 
* 
* 
* 
* 
* 
%* 
/ 


char *VioStrep( char zeichen, BYTE anz ) 


{ 
static char buf[133]; /* Puffer zum Aufbau des String */ 


/*-- Puffer mit Zeichen füllen und durch NUL abschließen --*/ 


memset( buf, zeichen, anz = ((anz > 132) ? 132 : anz) ); 
buflanz] = '\8'; /* das String-Ende setzen */ 
return buf; /* Pointer auf den Puffer zurückliefern */ 


PRRRRRBBRREBREBBERERERBRGREDBBGRREEREEREGERREREDEEDBRGEGBEEEE 
* Funktion >W.1.0-:8.4.11 
* 


: Einen Bildschirsbereich mit einen 
Zeichen füllen. 
X1, Yi = obere linke Ecke des Bereichs 
X2, Y2 = untere rechte Ecke des Ber. 
ZEICHEN= das Füll-Zeichen 
FARBE = Attribut für das Füll-Zeichen 
Su : keiner 
nfo £ 


SEK x 


a 2 E22. 205080502512 02 1212 .2.2 12.202.212 .2 12.2.2 .2.2.2.2.2 2.2202 0272 12.2.8 .2.2.2020202.202.20202.2 0202 .202.202 02.2.7 


Listing 2: (Fortsetzung) 
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SAA-Benutzeroberfläche in C 


void VioFill( BYTE x1, BYTE y1, BYTE x2, 
BYTE y2, char zeichen, BYTE farbe) 


{ 

char * line; /* Pointer auf eine auszugebende Zeile */ 
line = VioStrep( zeichen, x2-x1+1 ); /* Zeile aufbauen %*/ 
for ( ; yl <= e +y1) /* Zeilen durchlaufen */ 
} VioPrint( x1, yl, farbe, FALSE, line ); /* Zeile ausgeben */ 


:VioFrane 


: Zieht einen Rahmen um einen Bild- 
schirmbereich. 
: X1, Yi = obere linke Ecke des Bereichs 
X2, Y2 = untere rechte Ecke des Ber. 
RAHMEN = der Rahmen-Typ 
FARBE = Farbe des Rahmen 
Return-kert : keiner 
Info : = RAHMEN muß eine der folgenden Kon- 
stanten sein: EINRA, RA, VOLLRA, 
UNKTRA 


P 
- Verändert den VioStrep-Puffer! 


De Ze ze 22 22 22 Zu 2 Ze Zu ze 


void VioFrame( BYTE x1, BYTE yl, BYTE x2, 
BYTE y2, BYTE rahmen, BYTE farbe ) 


{ 
static char rahz[4][6] = { versch, | */ 


BYTE 1, k; /* Schleifenzähler */ 
char "strepu, /* Pointer auf den VioStrep-Puffer */ 
senkr; /* senkrechter Strich %*/ 


VioPrintf( x1, y1, farbe, FALSE, ”%c”, rahz[ rahmen ][ 8 ] ); 
VZURL xi+, 20 farbe, FALSE, 

z MaStrept ( rahz[ rahnen ][ 5 ], x2-x1-1 ) ); 
vi ntf( x2, farbe, FALSE, "%c", rahz[ rahmen it 10395 
= (senkr=rahz a jt 4 ], {eyl+, k=y2-1; 1 <= k; +1) 


VioPrintf( x1, i, farbe, FALSE, ”%c”, senkr ); 
rt x2, i , farbe, FALSE, "#%c”, senkr ); 


VioPrintf( x1, y2, farbe, FALSE, ”%c”, rahz[ rahmen ]J[ 2] ); 
VioPrint( x1+1, y2, farbe, FALSE, strepu ); 
N et x2, 'y2, farbe, FALSE, "%c", rahz[ rahmen ][ 3 ] ); 


[Pa BRENNEN EN RNE 
* Funktion :Vi1oScrollUp x 
Hu nn nn 
* Aufgabe : Scrollt einen Bildschirnbereich um * 
eine oder mehrere Zeilen nach oben. * 

Eingabe-Parameter: X1, Yi = obere linke Ecke des Bereichs * 
X2, Y2 = untere rechte Ecke des Ber. * 

ANZAHL = Anzahl der Zeilen, um die der * 

Bereich gescrollt werden soll * 

FARBE = Farbe für die Leerzeilen * 


(255 : kein Löschen d. Leerz. „ 
Return-Wert : keiner 
a petiadegerr 


void VioScrollUp( BYTE x1, BYTE y1, BYTE x2, 
B ‚ BYTE anzahl, BYTE farbe ) 


/# Laufzeiger */ 
/* Anzahl Bytes pro Zeile */ 


/* die Anzahl der Zeilen #/ 
/* die aktuelle Zeile */ 


Listing 2: (Fortsetzung) 
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anzb = (x2 - xi1 + 1) * VELLEN; 
anzy = y2 - (zeile = yl) + 1; /* Anzahl Zeilen */ 


for ( ; anzy ; --anzy, ++zeile) /* Zeilen durchlaufen */ 
{ /*' Pointer auf Anfang der zu übertragenen Zeile setzen */ 
alt = VPOS(x1, zeile); 
neu = VPOS(x1, zeile-anzahl); 
MOVE( alt, neu, anzb ); 


if ( farbe 1= 255 ) 


/* Anzahl Bytes */ 


/* Zeile kopieren */ 


/%* Leerzeilen löschen? */ 


} VioClear( x1, y2+1l-anzahl, x2, y2, farbe); /%* Ja */ 


[PRBBBREREBENREIERNRNNEBENENENEINE NENNEN EEE BIENEN NENNE 
:VioScrollDown 


Aufgabe » Scrollt einen Bildschirmbereich um 
* eine oder mehrere Zeilen nach unten. 
Eingabe-Parameter: X1, Yi = obere linke Ecke des Bereichs 
X2, Y2 = untere rechte Ecke des Ber. 
ANZAHL = Anzahl der Zeilen, um die der 
Bereich gescrollt werden soll 
FARBE = Farbe für die Leerzeilen 
(255 : kein Löschen d. Leerz. » 


RR 


Return-Wert : keiner 
void VioScrollDown( BYTE x1, BYTE y1, BYTE x2, 
BYTE y2, BYTE anzahl, BYTE farbe ) 

/* Laufzeiger */ 
int anzb; /* Anzahl Bytes pro Zeile */ 
BYTE anzy, /* die Anzahl der Zeilen */ 

zeile; /* die aktuelle Zeile */ 


/* Anzahl Bytes %*/ 
/* Anzahl Zeilen berechnen */ 


{ 
VPFAR alt, 
neu; 


anzb = (x2 - xi1 + 1) * VELLEN; 
anzy = (zeile = y2) - yl +1; 


for ( ; anzy ; --anzy, --zeile) /* Zeilen durchlaufen */ 
{ "Pointer auf Anfang der zu übertragenen Zeile setzen */ 
alt = VPOS(x1, zeile); 
neu = VPOS(x1, zeile+anzahl); 
MOVE( alt, neu, anzb ); /* Zeile kopieren */ 


} 
if ( farbe t= 255 ) /* Leerzeilen löschen? %*/ 
) VioClear( x1, yl, x2, yl+anzahl-1, farbe); /* Ja */ 


[EEE NENNEN 
:VioScrollHori 


: Scrollt einen Bildschirmbereich um 
eine oder mehrere Spalten nach links 
oder rechts. 

Eingabe-Paraneter: X1, Yi = obere linke Ecke des Bereichs 

x2, Y2 = untere rechte Ecke des Ber. 

ANZAHL = Anzahl der Spalten, um die 

der B. gescrollt werden soll 

FARBE = Farbe für die Leerspalten 

LEFT = TRUE, wenn der Bereich nach 

Links gescrollt werden soll. 
(255 : kein Löschen d. Leers. » 


EEE TEN 


* Aufgabe 


XKEKEKKEKRKKEKE KK 
ZKEKKKKKEKKE NK 


Return-Kert : keiner 
EEE: 


void VioScrollHori( BYTE x1, BYTE y!, BYTE x2, BYTE y2, 
BYTE anzahl, BYTE farbe, BYTE left ) 


{ 
VEL zbufl[ 132 ]; 
VPFAR alt, 


/* nimmt die jeweilige Zeile auf */ 
/* Laufzeiger */ 


neu, 
zptr = zbuf; /* Pointer auf den Zeilenpuffer %*/ 
int b; /* Anzahl Bytes pro Zeile */ 
BYTE /* die Anzahl Zeilen */ 
/* die aktuelle Zeile */ 
int R /* Entfernung ALT --> NEU %*/ 


Listing 2: (Fortsetzung) 


SAA-Benutzeroberfläche in C 


anzb = (x2 - xi + 1) * VELLEN; 
anzy = y2 - (zeile = yl) + 1; 

off = ( left ) ? -anzahl : anzahl; 
zptr = zbuf; 


/* Anzahl Bytes 
/* Anzahl Zeilen 
/* Entfernung setzen 


for (; ; --anzy, ++zeile) /* Zeilen durchlaufen 
{ Mm Pointer auf Anfang der zu übertragenen Zeile setzen 
neu = ( alt = VPOS(x1, zeile) ) + off; 


#ifndef NEARDATA /* in "kleinen” Speichermodell? 
MOVE( alt, neu, anzb ); /* Nein, Spalten kopieren 
#else /* Ja 
if ( left ) /* nach links scrollen? 
MOVE( alt, neu, anzb ); /* Ja, Spalten kopieren 
else /* Nein, nach rechts 

{ /* MOVEDATA kopiert immer von links --> rechts 
MOVE( alt, zptr, anzb ); /* erst in Puffer holen 
MOVE( zptr, neu, anzb ); /* von da wieder auf Bs. 


#endif 


} 
/*-- frei gewordene Spalten löschen 


if ( farbe = 255 ) /* Leerspalten löschen? */ 
if ( left ) /* Ja, nach Links scrollen? */ 
VioClear( x2-anzahl+1, yl, x2, y2, farbe); 

else /* Nein ‚ nach rechts scrollen “/ 
VioClear( x1, y1, x1+anzahl-1, y2, farbe); 


[ PERNNNEBNEENEEEN NENNNENENENNENERNENEBIENENENENNENERNNBNNE DI DNE BI EN 
* Funktion :VioMoveUp 


: Schiebt das aktuelle Fenster um eine 
oder mehrere Zeilen nach oben. 
Eingabe-Parameter: ANZAHL = Anzahl der Zeilen 
Return-Wert : TRUE, wenn das Fenster verschoben 
werden konnte, sonst FALSE 
Info : - Der Aufrufer trägt dafür Verant- 
vort, daß das Fenster nicht über 
den Bi dschira hinaus verschoben 
wird. 
- Der View-Bereich wird mit dem Fen- 
ster nach oben verschoben. 
- Befindet sich der Cursor innerhalb 
des Fensters, wird auch er ver- 


schoben. 
HR EBENEN BENENNEN BINNEN IN BEE NEEEEIENNENNIENNENENENEN NENNEN 


XKEKEKEKKKKE KK $ 


SEK * 


ah VioMoveUp( BYTE anzahl ) 


WIPTR wptr; /* Pointer auf aktuellen Fenster-Beschr. */ 

VEL * Bu /* Ptr. auf Puffer für überschriebenen B.ber. */ 

* aktbuf; /* aktueller Fensterpuffer */ 

BYTE a y» /* die Koordinaten des aktuellen Fenster */ 
» Yö; 


int zien; /* Länge des Zwischenspeichers 


e ( winopen ) /* ist überhaupt ein Fenster el ”/ 
* Ja 
wptr = winptr + winopen - 1; /* Ptr auf Fensterbeschr. 
bptr = (VEL *) malloc( zlen = BUFLEN(wptr->x1, 
Wr tr->x2, anzahl ) ); 
“ ( bptr ) /*. konnte ER wischensp. allokiert en Y 
* Ja * 
/#-- 1. Zeilen über Fenster in Zwischenspeicher holen -#*/ 
VioGet(x1 = wptr->x1, yl - anzahl, 
x2 = wptr->x2, ( yi = wptr-dy1 ) -1, bptr ); 


/*-- 2. Fenster um ANZAHL Zeilen nach oben scrollen ---*/ 
VioScrollUp( x1, yl, x2, y2=wptr->y2, anzahl, NOCLEAR ); 


/*-- 3. untere Zeilen des Fensters zurück auf Bilds. --*/ 


VioPut( x1, y2-anzahl+1, x2, y2, (aktbuf=wptr->winnem) + 
(x2-x1+1) * (y2-y1 -anzahl+1) ); 


Listing 2: (Fortsetzung) 


/#-- 4. frei gewordene Zeilen aus Puffer entfernen ----*/ 
memmove( aktbuf + (x2-x1+1) * anzahl, aktbuf, 
BUFLEN(x1, y1, x2, y2-anzahl ) ); 


/*-- 5. neu überdeckte Zeilen in Puffer kopieren 
memmove( aktbuf, bptr, zlen ); 


/#-- 6. Cursor versetzen 
if ( (x1 <= vspalte ) && (x2 >= vspalte ) && 
(yl <= vzeile ) && (y2 >= vzeile ) ) 
VioSetCursor( vspalte , vzeile - anzahl ); 


/#-- 7. Koordinaten im Fensterbeschreiber anpassen ----*/ 
wptr->yl -= anzahl; 

wptr->y2 -= anzahl; 

viewyl -= anzahl; 

viewy2 -= anzahl: 


free( bptr ); /* Zwischenspeicher wieder freigeben */ 
return TRUE; /®* geschafft! */ 


else /* es Konya kein Zuischenspeicher allokiert werden */ 
return FALSE * mit Fehler zurück */ 


else 


return FALSE; /* es ist kein Fenster geöffnet */ 


MER HEN NENE BNIEENENEE NN NNENENENEENE 
:VioMoveDown 


: Schiebt das aktuelle Fenster um eine 
oder mehrere Zeilen nach unten. 
Eingabe-Parameter: ANZAHL = Anzahl der Zeilen 
Return-Wert : TRUE, wenn das Fenster verschoben 
werden konnte, sonst FALSE 
Info : = Der Aufrufer trägt dafür Verant- 
wortung, daß das Fenster nicht über 
den Bi äschirn hinaus verschoben 
wird. 
- Der View-Bereich wird mit dem Fen- 
ster nach unten verschoben. 
- Befindet sich der Cursor innerhalb 
des Fensters, wird auch er ver- 


schoben. 
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ne VioMoveDown( BYTE anzahl ) 


WIPTR wptr; /* Pointer auf aktuellen Fenster-Beschr. */ 
VEL * bptr, /* Ptr. auf Puffer für überschriebenen B.ber. %*/ 
tbuf; /* aktueller Fensterpuffer */ 
BYTE x1, yl, /* die Koordinaten des aktuellen Fenster */ 
x2, y2; 

int zlen; 


7 ( winopen ) 


/®* Länge des Zwischenspeichers 
/* ist überhaupt ein Fenster Bet Den: */ 
* Ja 


wptr = winptr + winopen - 1; /# Ptr auf Fensterbeschr. 
bptr = ( *) malloc( zlen = BUFLEN(wptr->x1, 
1, wptr->x2, anzahl ) ); 
. ( bptr ) /* konnte ein wischensp. allokiert BR 
* Ja 
/#-- 1. Zeilen unter Fenster in Zwischenspeicher holen #/ 
VioGet(x1 = wptr->x1, y2+1, 
x2 = wptr->x2, ( y2 = wptr->y2 ) + anzahl, bptr ); 


/#-- 2. Fenster um ANZAHL Zeilen nach unten scrollen --*/ 
VioSerollDown(x1, yi=wptr->y1, x2, y2, anzahl, NOCLEAR ); 


/#-- 3. obere Zeilen des Fensters zurück auf Bilds. ---*/ 
VioPut( x1, yl, x2, yi+anzahl-1, (aktbuf=wptr->winmen) ); 


/*-- 4. frei gewordene Zeilen aus Puffer entfernen ----*/ 
memmove( aktbuf, aktbuf + (x2-x1+1) * anzahl, 
BUFLEN(x1, yl, x2, y2-anzahl ) ); 


Listing 2: (Fortsetzung) 
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/%-- 5. neu überdeckte Zeilen in Puffer kopieren 
memmove( (BYTE *) aktbuf + BUFLEN(x1, yl, x2, y2-anzahl), 
bptr, zlen ); 


/#-- 6. Cursor versetzen 
if.( (xl <= vspalte ) && (x2 >= vspalte ) & 
(yl <= vzeile ) && (y2 >= vzeile ) ) 
VioSetCursor( vspalte, vzeile + anzahl ); 


/#-- 7. Koordinaten im Fensterbeschreiber anpassen ----*/ 
wptr->yl += anzahl; 

wptr->y2 += anzahl; 

viewyl += anzahl; 

viewy2 += anzahl; 


free( bptr ); 
return TRUE; 


/* Zwischenspeicher wieder freigeben */ 
/#* geschafft! */ 


else /* es konnte kein Zwischenspeicher allokiert werden */ 


/*-- 4. frei gewordene Spalten aus Puffer entfernen ---*/ 

lptr = aktbuf; /* Ptr auf Fensterpuffer */ 
= (off - anzahl) * VELLEN; /* zu versch. Bytes */ 
or (i = yl; i <= y2; ++1, Iptr += off ) 

nemmove( Iptr, Iptr + anzahl, j ); 


/#-- 5. Cursor versetzen 
if ( (x1 <= vspalte ) && (x2 >= voraiie ) && 
(yl <= vzeile ) && (y2 >= vzeile ) ) 
VioSetCursor( vspalte + anzahl , vzeile ); 


/*-- 6. neu überdeckte Zeilen in Puffer kopieren #/ 
Ipe = aktbuf + (x2-x1+1-anzahl) ; /* Ptr auf F.puffer */ 
lbptr = Dpeeı /* Ptr auf Zwischenpuffer %/ 

N = anzahl * VELLEN; /* zu verschiebende Bytes */ 
or ( ; yl <= y2; ++yl, Iptr += off, lbptr += anzahl ) 
memmove( Iptr, lbptr, j ); 


/*--7. Koordinaten im Fensterbeschreiber anpassen 


return FALSE; /% nit Fehler zurück %*/ wptr->x1 += anzahl; 
wptr->x2 += anzahl; 
else viewx += anzahl; 
return FALSE; /* es ist kein Fenster geöffnet */ viewx2 += anzahl; 
free( bptr ); 


return TRUE; 


/* Zwischenspeicher wieder freigeben */ 
[ROROBSGBBEBERGBRBBBBBBGHROBBBEGDSGBGEREBBBGRBREGBRBBORBGBRREEEE /* geschafft! */ 


:VioMoveRight 


» Schiebt das aktuelle Fenster um eine 
oder mehrere Spalten nach rechts. 
Eingabe-Parameter: ANZAHL = Anzahl der Spalten 
Return-Wert : TRUE, wenn das Fenster verschoben 
werden konnte, sonst FALSE 
Info : = Der Aufrufer trägt dafür Verant- 
Fa daß das Fenster nicht über 
den Bildschirm hinaus verschoben 
wird. 
- Der View-Bereich wird mit dem Fen- 
ster nach rechts verschoben. 
- Befindet sich der Cursor innerhalb 
des Fensters, wird auch er ver- 
schoben. 


else /* es konnte kein Zwischenspeicher allokiert werden */ 
return FALSE; /* mit Fehler zurück %/ 
} 


else 


N return FALSE; /* es ist kein Fenster geöffnet */ 


/ EEE ARE A DE DI BD DR DE NEE EEE NENNE KEINEN EIER: 
:VioMoveLeft 


: Schiebt das aktuelle Fenster um eine 
oder mehrere Spalten nach links. 
Eingabe-Parameter: ANZAHL = Anzahl der Spalten 
Return-Wert : TRUE, wenn das Fenster verschoben 
werden konnte, sonst FALSE 
Info : = Der Aufrufer trägt dafür Verant- 
wortung, daß das Fenster nicht über 
den Bildschirm hinaus verschoben 
wird. 
- Der View-Bereich wird mit dem Fen- 
ster nach links verschoben. 
- Befindet sich der Cursor innerhalb 
des Fensters, wird auch er ver- 
schoben. 
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ne VioMoveRight( BYTE anzahl ) 


WIPTR wptr; 
VEL * Bir 
* buf, 
* Ipr 
* ]bptr; 
BYTE x1, yl, 
x2 


 Yöı 
off, /* Offsetwert zum Durchlaufen des Puffers 
1,93; /* Schleifenzähler 
int zlen; /* Länge des Zwischenspeichers 


e ( winopen ) 


/* Pointer auf aktuellen Fenster-Beschr. 

/* Ptr. auf Puffer für überschriebenen B.ber. 
/* aktueller Fensterpuffer 

/* Laufzeiger in- Fensterpuffer 

/* Laufzeiger in Zwischenspeicher 

/* die Koordinaten des aktuellen Fenster 


EHRE EEE NEE AERR EERE 


| 
| 
| 
| 


Pi VioMoveLeft( BYTE anzahl ) 


WIPTR wptr; /* Pointer auf aktuellen Fenster-Beschr. 
VEL * bptr, /* Ptr. auf Puffer für überschriebenen B.ber. 
wptr = winptr + winopen - 1; /* Ptr auf Fensterbeschr. * aktbuf, /* aktueller Fensterpuffer 
bptr = (VEL *) malloc( zlen = BUFLEN(1, wptr->y1, * ]ptr, /* Laufzeiger in Fensterpuffer 

anzahl, RR 95 * ]bptr; /* Laufzeiger in Zwischenspeicher 
a ( bptr ) al 


/* ist überhaupt ein Fenster geöffnet? 
/* Ja 


/%* konnte ein Zwischensp. okiert N a, BYTE x1, yl, /* die Koordinaten des aktuellen Fenster 
* Ja # 
/#-- 1. Spalten neben Fenster in Zwischensp. holen ----*/ 
VioGet( x2 + 1, yl = wptr->yl, (x2 = wptr->x2) + anzahl, 
y2 = wptr-)y2, bptr ); int 


/* Offsetwert zum Durchlaufen des Puffers 
/* Schleifenzähler 
/* Länge des Zwischenspeichers 


/#-- 2. Fenster um ANZAHL Spalten n. rechts scrollen --*/ 
VioScrollRight( x1 = wptr->x1, yl, x2, y2, 
anzahl, NOCLEAR ); 


/#-- 3. linke Spalten des Fensters zurück auf Bilds. --*/ 
lptr = aktbuf= wptr->winnen; /* Ptr auf Pufferanfang */ 
off=(x2-x1+1); /# kan einer Zeile in VEL */ 
N = x + anzahl - 1; /* rechte Spalte für VioPut %#/ 
or (1 = yl; 1 <= y2; +4, Iptr += off ) 

VioPut( x1, 4, j, 1, Iptr ); /* eine Zeile zurück */ 


" ( winopen ) /* ist überhaupt ein Fenster au 
* Ja 
wptr = winptr + winopen - 1; /# Ptr auf Fensterbeschr. 
bptr = ( *) malloc( zlen = BUFLEN(1, wptr->y1, 
anzahl, wptr->y2 ) ); 
if ( bptr ) /* konnte ein Zwischensp. allokiert werden? */ 
{ /* Ja */ 
/#-- 1. Spalten neben Fenster in Zwischensp. holen ----*/ 
VioGet( x - anzahl, yl = wptr->yl, (x1 = wptr->x1) - 1, 
y2 = wptr->y2, bptr ); 


Listing 2: (Fortsetzung) Listing 2: (Fortsetzung) 
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/#-- 2. Fenster um ANZAHL Spalten nach links scrollen -%/ 
VioScrollleft( x1, yl, x2 = re y2, 
anzahl, NOCLEAR ); 


/#-- 3. rechte Spalten des Fensters zurück auf Bilds. -#/ 
off=-(x2-xi+1); /* Länge einer Zeile in VEL %/ 
lptr = (aktbuf = wptr->winmem) + off - anzahl; 

= x2 - anzahl + 1; /* linke Spalte für VioPut */ 
or (1 = yl; i <= y2; ++i, Iptr += off ) 
VioPut( j, i, x2, i, Iptr ); /* eine Zeile zurück %*/ 


/*-- 4. frei gewordene Spalten aus Puffer entfernen ---*/ 

lptr = aktbuf; /* Ptr auf Fensterpuffer */ 
= (off - anzahl) * VELLEN; /* zu versch. Bytes */ 
or (i = yl; 1 <= y2; ++1, 1Iptr += off ) 

memmove( Iptr + anzahl, Iptr, j ); 


/®-- 5. Cursor versetzen 

if ( (x1 <= vspalte ) && (x2 >= vspalte ) && 
(yl <= vzeile ) && (y2 >= vzeile ) ) 

VioSetCursor( vspalte - anzahl , vzeile ); 


/#-- 6. neu überdeckte Zeilen in Puffer kopieren 

lptr = aktbuf; /* Ptr auf Fensterpuffer */ 

lbptr = bptr; /* Ptr auf Zwischenpuffer */ 
= anzahl * VELLEN; /* zu verschiebende Bytes */ 
or ( ; yl <= y2; ++yl, lptr += off, lbptr += anzahl ) 
memmove( Iptr, lbptr, j ); 


/#-- 7. Koordinaten im Fensterbeschreiber anpassen ----*/ 
wptr->x1 -= anzahl; 
tr->x2 -= anzahl; 
viewxi -= anzahl; 
viewx2 -= anzahl; 


free( bptr ); 
jean TRUE; 


/* Zwischenspeicher wieder freigeben */ 
/* geschafft! */ 


else /* es konnte kein Zwischenspeicher allokiert werden */ 
return FALSE; /* mit Fehler zurück */ 


else 


y return FALSE; /* es ist kein Fenster geöffnet */ 


[ %RRR NEN EEK NEE NENNEN NN NND EBENE 
* Funktion :VioSetWin 


: Schiebt das aktuelle Fenster an eine 
neue Bildschirmposition. 
Eingabe-Parameter: XNEU, = neue Koordinate der oberen 
YNEU linken Fensterecke 
: TRUE, wenn das Fenster verschoben 
werden konnte, sonst FALSE 
Info : = Der Aufrufer trägt dafür Verant- 
wortung, dap das Fenster nicht über 
den Bildschirm hinaus verschoben 
wird. 
- Der View-Bereich wird mit dem Fen- 
ster verschoben. 
- Befindet sich der Cursor innerhalb 
des Fensters, wird auch er ver- 
schoben. 


Return-kert 


ZKEEKKKKEKKEKKE RK CK KK KK x 


i 
i 
5 
* 
i 
| 
x KEKEKKEKEKE KK K < 


Pl VioSetkin( BYTE xneu, BYTE yneu ) 


/* Pointer auf aktuellen Fenster-Beschr. */ 

ie: /* Ptr. auf Puffer für überschriebenen B.ber. */ 
buf; /* aktueller Fensterpuffer */ 
al, yl, /* die Koordinaten des aktuellen Fenster */ 
/* Länge des Zwischenspeichers */ 

/* Entfernung des neuen vom alten */ 

/* Fenster in Spalten und Zeilen */ 


Listing 2: (Fortsetzung) 


/* ist überhaupt ein Fenster geöffnet? */ 
/" Ja */ 
wptr = winptr + winopen - 1; /* Ptr auf Fensterbeschr. */ 
bptr = (VEL *) malloc( BUFLEN( x1 = wptr->x1, 
y! = wptr->yl, x2 = wptr->x2, y2 = wptr->y2 ) ); 
v ( bptr ) /* konnte ein Zwischensp. allokiert MEER u 
* Ja 


u ( winopen ) 


/#-- 1. den Fensterinhalt in Zwischenspeicher holen ---#/ 
VioGet( x1, y1l, x2, y2, bptr ); 


/#-- 2. Bildschirminhalt unter Fenster zurückbringen --*/ 
VioPut( x1, yl, x2, y2, aktbuf = wptr->winmem ); 


/#-- 3. Cursor versetzen 
if ( (x1 <= vspalte ) && (x2 >= vspalte ) && 
(y1 <= vzeile ) && (y2 >= vzeile ) ) 
VioSetCursor( vspalte - x! + xneu, 
vzeile - yl + yneu ); 


/#-- 4. Bildschirminhalt an neuer Pos. holen 
xdif = xneu - x1; /* Entfernung: Spalten */ 
ydif = yneu - yl; /* Entfernung: Zeilen */ 
VioGet( wptr->x1 = xneu, wptr->yl = yneu, 

wptr->x2 = x2 = x2rxdif, 

wptr->y2 = y2 = y2+ydif, aktbuf ); 


/#-- 5. Fensterinhalt an neue Position bringen 
VioPut( xneu, yneu, x2, y2, bptr ); 


/#-- 6. View-Bereich an die neue Position anpassen ----*/ 
viewxi += xdif; 
viewyl += ydif; 
viewx2 += xdif; 
viewy2 += ydif; 


free( bptr ); 
return TRUE; 


/* Zwischenspeicher wieder freigeben */ 
/* geschafft! */ 


else /* es konnte kein Zwischenspeicher allokiert werden */ 
j return FALSE; /* ait Fehler zurück */ 


else 


return FALSE; /* es ist kein Fenster geöffnet */ 


[Me ME EN NENNEN NENNEN NN NENNEN 
:VioCGolor 


: Färbt einen Bildschirmbereich mit 
einem konstanten Attribut ein. 
Eingabe-Parameter: X1, Yi = obere linke Ecke des Bereichs 
X2, Y2 = untere rechte Ecke des Ber. 
FARBE = Farbe der einzelnen Zeichen 


Aufgabe 


Return-kert 
void VioColor(BYTE x1, BYTE y1, BYTE x2, BYTE y2, BYTE farbe) 


/* Laufzeiger %*/ 


{ 
3 Coryal VPFAR Iptr; 
B s /* Schleifenzähler %*/ 


/*-- die einzelnen Zeilen durchlaufen 


for (j=x2 - x1 + 1 ; yl <= y2; ++y1) 

{ /* die einzelnen Zeichen der Zeile durchlaufen */ 
for (lptr = VPOS(x1, yl), 1=j;1; --1) 

} (1ptr++)->h.attribut = farbe; /* die Farbe setzen */ 


Listing 2: (Ende) 
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VioGet bedient sich zum Kopieren der Daten aus dem 
Video-RAM in den angegebenen Puffer des Makros move, 
das innerhalb des VIO-Moduls definiert wird und je nach 
dem Speichermodell, unter dem das VIO-Modul kompiliert 
wird, in einen Aufruf der movedata- oder der memmove- 
Funktion umgesetzt wird. Diese Unterscheidung ist not- 
wendig, da in den Speichermodellen Small und Medium 
immer mit NEAR-Pointern gearbeitet wird und dadurch 
mit Hilfe von memmove keine Daten zwischen dem Puffer 
innerhalb des Datensegments und dem Video-RAM kopiert 
werden können. Anstelle von memmove muß hier deshalb 
auf movedata zurückgegriffen werden. 


VioPut 

Ein Bildschirmbereich dessen Inhalt zuvor über VioGet 
in einen Puffer geholt wurde, kann durch den Aufruf von 
VioPut wieder auf den Bildschirm gebracht werden. Da 
VioPut den Puffer, aus dem es die Zeichen und ihre Attri- 
bute entnimmt, nicht verändert, kann ein Puffer durch 
mehrmalige Aufrufe von VioPut unter der Angabe unter- 
schiedlicher Bildschirmkoordinaten an verschiedene Bild- 
schirmpositionen gebracht werden. 

Auch VioPut bedient sich zum Kopieren der Daten aus 
dem Puffer in den Video-RAM des move-Makros. 


VioWinOpen 

Durch den Aufruf dieser Funktion wird ein Bildschirm- 
fenster geöffnet, wobei ein entsprechender Eintrag der 
Struktur windes angelegt und in ihm die Koordinaten des 
Fensters, die Koordinaten des aktuellen View-Bereichs 
sowie die aktuelle Cursorposition abgespeichert werden. 
Zusätzlich wird der Inhalt des Bildschirmbereichs, den das 
Fenster überdeckt, mit Hilfe von VioGet in einen Puffer 
geholt, der über den Heap allokiert wird. 

Steht nicht mehr genügend Speicher auf dem Heap 
bereit, um einerseits den Fenster-Vektor zu vergrößern und 
andererseits einen Puffer zur Aufnahme des Bildschirm- 
bereichs zu allokieren, liefert die Funktion die Konstante 
FALSE, die in der Datei VIO.H definiert wird, an den Auf- 
rufer zurück. Konnte das Fenster jedoch einwandfrei geöff- 
net werden, wird dem Aufrufer die Konstante TRUE über- 
geben. 


VioWinClose 

Diese Funktion bildet das Gegenstück zu VioWinOpen 
und schließt das jeweils zuletzt geöffnete Fenster wieder. 
Der Aufrufer kann dabei durch Übergabe eines Parameters 
entscheiden, ob der alte Bildschirminhalt unter dem Fenster 
wieder hergestellt wird. Spricht sich der Aufrufer dafür aus, 
wird gleichzeitig auch der Cursor wieder auf die Position 
gesetzt, die er vor dem Öffnen des Fensters inne hatte. 
Gleiches gilt für den View-Bereich, der ebenfalls zurückge- 
setzt wird. 
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VioSetCursor 

Der blinkende Bildschirmcursor wird durch diese 
Funktion auf die angegebene Bildschirmposition versetzt. 

Die aktuelle Cursorposition kann vom Anwendungs- 
programm aus jederzeit mit Hilfe der Makros aktz und 
akts abgefragt werden, die in der Datei VIO.H definiert 
werden. 

Auf der Funktion VioSetCursor basiert auch das 
Makro VioHideCursor mit dessen Hilfe der Cursor auf 
eine Position außerhalb des Bildschirm gesetzt und damit 
unsichtbar gemacht wird. 


VioPrint 

Der Ausgabe einer Zeichenkette auf dem Bildschirm 
dient die Funktion VioPrint. Neben der Ausgabeposition 
auf dem Bildschirm kann der Aufrufer auch die Farbe bzw. 
das Attribut bestimmen, in der die Zeichen auf dem Bild- 
schirm erscheinen sollen. Ein weiterer Parameter entschei- 
det darüber, ob der Cursor nach der Ausgabe hinter das 
letzte ausgegebene Zeichen bewegt wird, oder ob er auf 
seiner aktuellen Position verharren soll. 

Beachten Sie bitte, daß VioPrint alle Zeichen der Zei- 
chenkette unbearbeitet auf den Bildschirm bringt und Steu- 
erzeichen wie z.B. Carriage Return oder Bell als ganz nor- 
male ASCII-Zeichen behandelt. 


VioPrintf 

Diese Funktion ähnelt der printf-Funktion jedoch mit 
dem Unterschied, daß hier die Ausgabeposition auf dem 
Bildschirm und die Farbe der auszugebenden Zeichen vom 
Aufrufer festgelegt wird. Ansonsten können die gewohnten 
Formatierungskennzeichen von printf (%d, %f etc.) in 
vollem Umfang benutzt werden. 


VioStrep 

Immer wieder kommt es vor, daß ein Zeichen mehrmals 
hintereinander ausgegeben oder in eine Zeichenkette ein- 
gebunden werden soll. In einem solchen Fall leistet Vio- 
Strep wertvolle Hilfe, indem es einen String generiert, der 
aus einer bestimmten Anzahl von Zeichen besteht, wobei 
der Aufrufer sowohl die Anzahl (im Bereich zwischen 1 und 
80), als auch das zu wiederholende Zeichen frei definieren 
kann. 


VioFill 

Ein bestimmter Bildschirm kann mit Hilfe dieser Funk- 
tion mit einem konstanten Zeichen unter einer konstanten 
Farbe gefüllt werden. Neben den Eckkoordinaten des Bild- 
schirmbereichs muß dieser Funktion auch das Füllzeichen 
und eine Farbe für dieses Zeichen übergeben werden. 
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Auf dieser Funktion basieren auch die Makros Vio- 
Clear und VioClearScreen aus der Datei VIO.H, mit 
deren Hilfe der gesamte Bildschirm gelöscht, bzw. ein Teil 
des Bildschirms mit Leerzeichen gefüllt werden kann. 


VioFrame 

Fenster werden vom übrigen Bildschirminhalt oft durch 
eine andere Farbe oder einen Rahmen optisch hervorge- 
hoben. Der letzteren Aufgabe widmet sich die Funktion 
VioFrame, die einen von 4 verschiedenen Rahmen um 
einen Bildschirmbereich zieht. Der umrahmte Bildschirm- 
bereich und die Farbe des Rahmens können dabei vom 
Aufrufer frei gewählt werden. Der Rahmentyp muß einer 
der Konstanten (EINRA, DOPRA etc.) entsprechen, die in 
der Datei VIO.H definiert werden. 


VioScrollUp 

Durch den Aufruf dieser Funktion wird der angegebene 
Bildschirmbereich um eine oder mehrere Bildschirmzeilen 
nach oben gescrollt. Sollen die dadurch frei werdenden 
Bildschirmzeilen am unteren Rand des Bereichs gelöscht 
werden, kann der Aufrufer ein Farbe für diese Zeilen ange- 
ben. Sollen diese Zeilen hingegen nicht gelöscht werden, 
muß der Aufrufer als Farbe die Konstante NOCLEAR aus 
der Datei VIO.H an VioScrol1lUp übergeben. 


VioScrollDown 

Diese Funktion entspricht vom Aufruf her der Funktion 
VioScrollUp mit dem Unterschied, daß sie den angege- 
benen Bildschirmbereich nicht nach oben, sondern nach 
unten scrollt. 


VioSrcollHori 

Analog zu den Funktionen VioScrollUp und Vio- 
ScrollDown wird ein Bildschirmbereich durch den Aufruf 
dieser Funktion um eine oder mehrere Spalten nach links 
oder nach rechts verschoben. Der Aufrufer sollte diese 
Funktion jedoch nicht direkt, sondern über die beiden 
Makros VioScrollLeft und VioScrollRight aus der 
Include-Datei VIO.H aufrufen. 

Auch bei VioScrollHori gilt, daß das Löschen der 
freigewordenen Spalten unterbleibt, wenn als Farbe die 
Konstante NOCLEAR übergeben wird. 


VioMoveÜp, VioMoveDown, 
VioMoveLeft, VioMoveRight 

Diese Funktionen verschieben jeweils das aktuelle Fen- 
ster um die angegebene Anzahl von Spalten oder Zeilen in 
die entsprechende Richtung. Mit dem Fenster verschiebt 
sich auch der View-Bereich und die Position des blinkenden 


Bildschirmcursors, sofern dieser sich innerhalb des zu ver- 
schiebenden Fensters befindet. Der Aufrufer hat dabei 
dafür Sorge zu tragen, daß das Fenster nicht über den Bild- 
schirmrand hinaus verschoben wird. 


VioColor 

Die letzte Funktion innerhalb des VIO-Moduls dient der 
Einfärbung eines Bildschirmbereichs mit eine konstanten 
Farbe bzw. Attribut ohne daß die einzelnen Zeichen inner- 
halb des Bereichs verändert werden. 


Das Demo-Programm 


Damit die Beschreibung dieser Funktionen nicht nur graue 
Theorie bleibt, sondern auch in die Praxis umgesetzt wer- 
den kann, demonstriert Ihnen das kleine Demo-Programm 
(Listing 3) den Aufruf fast aller Funktionen des VIO- 
Moduls. Wie auch das VIO-Modul selbst ist es sehr aus- 
führlich dokumentiert und sollte daher keine Fragen offen 
lassen. Wie auch das Vio-Modul selbst, kann auch das 
Demo-Programm in Verbindung mit allen Speichermodel- 
len des Microsoft C-Compilers eingesetzt werden. Um das 
Demo-Programm beispielsweise unter dem Small-Modell 
zu kompilieren geben Sie bitte: 


CL /AS viodemo.c vio.c 


ein. Ist das VIO-Modul einmal unter dem entsprechen- 
den Speichermodell kompiliert worden, reicht es aus, das 
Modul mit Ihrem jeweiligen Programm während des Link- 
vorgangs zu verbinden. Eine erneute Kompilierung des 

VIO-Moduls muß dann also nicht mehr stattfinden. 
Michael Tischer 


Michael Tischer ist Autor mehrerer Fachbücher über DOS 
und die Programmierung auf Personalcomputer. Sein bekann- 
testes Buch ist »PC Intern«, das umfassendste deutsche Werk 
zur PC-Programmierung, das gerade in einer erweiterten und 
überarbeiteten Auflage herausgekommen ist. 


[WWORBERBBBRRERBRBRBRIRERREBBRBKBRIBEREEEBBRRBRREREENIRNIE/ 


VIODEMO.GC 


: Demonstriert die Arbeit mit den ver- */ 
schiedenen Funktionen des VIO-Moduls.*/ 


*/ 
» MICHAEL TISCHER 
entwickelt an : 1.12.1988 
letztes Update : 6.12.1988 


: CL /ALSINICILIH] VIODEMO.C VIO.C 


Erstellung 


[ROHR EEE RR / 


Listing 3: VIODEMO.C 
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SAA-Benutzeroberfläche in C 


/#-- Include-Dateien einbinden -----------------— Eee), 
Finclude "vio.h” /* für die Funktionen aus VIO.C ®/ 
#include <stdlib.h> /* für RAND() */ 
include <math.h> /* für SIN() ®/ 
Zinclude <time.h> /* für TIME() %/ 
#include <conio.h> /* für GETCH() %/ 


/* holt Farbe 
Farbe für "Taste betätigten” 
/* Farbe “a Rahmen im unstersten Fenster 
/* Farbe des ersten Fenster 
/* Rahmenfarbe Demo-Fenster 1 
/* Textfarbe Demo-Fenster | 
/* Rahmenfarbe Demo-Fenster 2 */ 
/* Textfarbe Demo-Fenster 2 
/* Rahnenfarbe Demo-Fenster 3 
/%* Textfarbe Demo-Fenster 3 
/* Rahmenfarbe Demo-Fenster 4 
/* Textfarbe Demo-Fenster 4 
/* Rahmenfarbe Demo-Fenster 5 */ 
/* Textfarbe Demo-Fenster 5 */ 
/* Rahnenfarbe Demo-Fenster 6 */ 
/* Textfarbe Demo-Fenster 6 
/%* Rahnenfarbe Demo-Fenster 7 
/* Textfarbe Demo-Fenster 7 
/* Rahmenfarbe Demo-Fenster 8 
/* Textfarbe Demo-Fenster 8 
/* Rahmenfarbe Ende-Fenster 
/* Textfarbe Ende-Fenster 
/* Farbe für Copyright 


de 
AR mer (*FUP) (void); 


/#-- Strukturen 
struct vdata ( n beschreibt Eingabedaten für VioDemo 
BYTE rt, /* Rahmentyp für Info-Fenster 
/* Rahmenfarbe als Index 

/* Textfarbe als Index 

/* Pointer auf Vektor mit Ptr 

/* Pointer auf Fkt 


/* Demo-Funktionen 


void demo4( void ); 
void demo5( void ); 
void demo6( void ); 
void demo?( void ); 
void demoß( void ); 


/#-- globale Variablen */ 
BYTE colvek[])] = { /* Farben für Farb-Modus */ 


BLINK( COL( WEISS, ae I), /* TEC */ 


' I MR */ 
GELB, SCHWARZ ), /® MB ®/ 
WEISS, CYAN ), /® DERI %#/ 
GELB, CYAN ), /* DFTI %/ 
SCHWARZ, VIOLETT ), /* DFR2 %/ 
WEISS, VIOLETT ), 
HBLAU, BLAU ), 
WEISS, BLAU ), 
ROT, DGRAU ), 
SCHWARZ, DGRAU ), 
CYAN, BLAU ), 
GELB, BLAU ), 
GELB, 


COL( WEISS, ROT ), 
COL( HEISS, CYAN ), 
COL( GELB 

COL( HBLAU, BLAU ), 
COL( WEISS, BLAU ), 
COL( SCHWARZ, VIOLETT ), 
COL( WEISS, VIOLETT ), 
COL( GELB, CYAN ) 


Listing 3: (Fortsetzung) 
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/* Attribute für Monochrom-Modus */ 
BLINK( INVERS ), / 
NORMAL 


BYTE *farbvek; /* Pointer auf aktiven Farb-Vektor #/ 


(== DRVen > 2OR\DEBO. TE = een nennen nee er #/ 
war: #il] = /* Text für Demo-Fenster 1 */ 


4 VIODEMO Tmuu”. 


amm soll Ihnen”, 
tionen aus dem”, 


"Dieses kleine Demonstrationspro 
"die Leistungsfähigkeit der 
"VIO-Modul verdeutlichen.” 
"Zu diesem Zweck werden Ihnen nacheinander die”, 
ee Funktionen dieses Moduls vorge-”, 
"stellt.. 
2 
}; 
struct vdata dfi = { /* Daten für Demo-Fenster 1 */ 
EINRA, DFR1, DFTI, t1, (FUP) 8 


/*-- Daten für Demo 2 
char *t2[] = 


/ 
/* Text für Demo-Fenster 2 */ 
{ "Eingeleitet wird die Arbeit mit den Funktionen des VIO-", 
"Moduls durch den Aufruf der Funktion”, 


' Violnit()"”, 


"die die internen Variablen des VIO-Moduls initialisiert”, 
"und das Modul auf die aktive Videokarte einstellt.”, 


"Danach können Fenster mit Hilfe der Funktionen”, 
„' VioWinOpen() und VioWinClose()”, 


"nach dem LIFO-Prinzip geöffnet und wieder geschlossen”, 
"werden. Die Anzahl der ee geöffneten Fenster”, 
"wird dabei nur durch die Größe des freien Speicher-”, 
"platzes auf dem Heap beschränkt.”, 

"eo" 


}; 
struct vdata df2 = { 


/* Daten für Demo-Fenster 2 */ 
EINRA, DFR2, DFT2, t2, demo2 


/*-- Daten für Demo 3 
char *3[] = /* Text für Demo-Fenster 3 Y 
{ "Der Inhalt eines Bildschirmbereichs kann mit Hilfe”, 

"der Funktion”, 


n' Viorilld)", 


Listing 3: (Fortsetzung) 


Microsoft Symposium 


»Dynamisch Zeichnen mit Micro- 
soft Excel« war der Titel einer Präsen- 
tation am Stand der Management 
Informations Systeme. Dabei wurde 
hier nicht eigentlich eine Branchen- 
lösung vorgestellt, sondern ein sinn- 
volles Zusatzprodukt zu Excel. Die 
Anwendung »Zeichnen« versetzt Excel 
in die Lage, einfache geometrische 
Elemente wie Linien, Polygone, Krei- 
se, Intensitätspfeile und Rechtecke 
darzustellen. Im Gegensatz zu norma- 
len Zeichenprogrammen aber handelt 
es sich bei den Zeichen dieser Appli- 
kation um »dynamische Zeichen«. Sie 
werden durch Kalkulationswerte aus 
Excel-Tabellen definiert. Ändern sich 
daher die Tabellenwerte, so ändern 
sich auch automatisch die Zeichen - 
eine sinnvolle Erweiterung der DTP- 
Fähigkeiten von Microsoft Excel. 

Was der Aussteller zum Zeitpunkt 
der Frankfurter Windows-Messe noch 
nicht wußte: Die Anwendung »Zeich- 
nen« wurde von der Jury des PC 
Magazin-Wettbewerbs um die beste 
Excel-Anwendung als so gelungen 
betrachtet, daß sie mit dem ersten 
Preis bedacht wurde. 

Mehr als 400 Händler, Industrie- 
vertreter und Journalisten besuchten 
die Ausstellung deutscher Windows- 
und Excel-Applikationen. Die Ange- 
botspalette war breit. Sie reichte von 
grafisch orientierten DTP-Lösungen 
über ingenieurwissenschaftliche CAD- 
Anwendungen bis zu Buchhaltungs- 
programmen. Christian Wedell, 
Microsoft-Geschäftsführer und inter- 
essiertester Besucher der ganzen Aus- 
stellung, hat versprochen, daß dies 
nicht die letzte Windows-Schau in 
deutschen Landen gewesen sein soll. 
Microsoft will sich im Gegenteil künf- 
tig intensiver um die Verbreitung von 
Produkten unabhängiger, aber mit 
Microsoft kooperierender Hersteller 
kümmern. Dies soll im Rahmen eige- 
ner, aber auch unabhängiger Messen 
geschehen. Schließlich hat Microsoft 
durch MS OS/2 und seine SQL- und 
Netzwerktechnologie deutlich den 
Weg in Richtung »Systemhaus« einge- 
schlagen. 


Microsoft C 


int far * far p; 


p ist ein entfernter Zeiger auf eine 
far-Integer. 


Zum Abschluß 


Sie sind nun mit C-Deklarationen und 
den »Verkehrsregeln« gut genug ver- en 
traut, um die Beispiele vom Anfang E 
nachvollziehen zu können. Versuchen 
Sie diese zu lösen, bevor Sie weiter- 
machen. Um sicher zu sein, daß wir 
alle übereinstimmen: 


struct vtag far * 


(far * const far varl[5])(); 


bedeutet, daß var ein konstan- 
tes entferntes Array von 5 Zeigern auf 
far-Funktionen ist, die Zeiger auf die 
far-Strukturen vtag liefern. 


Nach 5 106 UrhG ist das Kopieren von urheberrechtsgeschützten Computerprogrammen strafbar. 


N 


wareschnittstellen erforderlich, die in die- 


EiHip wiss 


Gunter Biethan: 


Systemprogrammierung unter 
MS-DOS/PC-DOS 


472 Seiten, 84 Bilder, Hardcover sem Buch vermittelt werden. Neben 
58,— DM,/ISBN 3-8023-0178-1 Funktion, Programmiermodellen und 
Personalcomputer, die unter dem Befehlssätzen der wichtigsten MS-DOS- 
Betriebssystem MS-DOS bzw. PC-DOS fähigen Mikroprozessoren werden die 
arbeiten, gelten allgemein als „Standard“. BUS- und Peripherieschnittstellen 

Um anspruchsvolle systemnahe Problem- beschrieben. Damit steht die Behandlung 
lösungen zu entwickeln, sind weiter- der DOS-Interrupts und Funktionsaufrufe 
gehende Kenntnisse der Hard- und Soft- im sinnvollen Systemzusammenhang. 


Gunter Biethan: 


MS-DOS/PC-DOS kurz und bündig 


Versionen 2.1 bis 3.3 


248 Seiten, 13 Bilder, 20 Tabellen Dem Wunsch vieler Anwender von MS- 
38,— DM/ISBN 3-8023-0866-2 DOS folgend, wurde die Beschreibung der 
Dieses Buch baut dem Anwender eine nicht zum Betriebssystem gehörenden 
Brücke zum besseren Verständnis und zur Hilfsprogramme „EDLIN“ und „DEBUG“ 
leichteren Bedienung seines PCs, um ihm in dieses Buch mit aufgenommen. 

so den Weg zur aktiven, erfolgreichen Der Buchinhalt bezieht sich auf die Ver- 
Computerei zu ebnen. sionen bis einschl. 3.3; ein Ausblick auf 

Es soll nicht das Handbuch ersetzen, 05/2 bzw. BS/2 (ursprünglich angekündigt 
sondern geht gezielt auf en als MS-DOS-Version 5.0) wird ebenfalls 
Anwenderprobleme und -fragen ein, wie: angeboten. 

Haben Sie schon den neuen & VOGEL B chverla Würzbu 
‚.CHIP- Katalog '52% ' u g rg 
Bestellen Sie gleich! Postfach 6740 - 8700 Würzburg 1 


MS-QUICK C 


aktuelle US-Version 


a DM 148,00 


unverbindliche Preisempfehlung TO OÖ L BO x 


ISAM + Windowing 


Im Software-Fachhandel DM 282, 72 


unverbindliche Preisempfehlung 


erwähnte Warenzeichen: MS-QUICK € (Microsoft GmbH); Toolbox (BKS Software GmbH). 


MICROSOFT EXCEL ODER 
DIE LIEBE ZUR 
TABELLENKALKULATION. 


1. Aufzug, 1, Szene: Anwender, Entscheider, PC 
und Microsoft Excel. 


Anwender (enttäuscht): Grau, teurer Freund, ist alle Theorie... 

PC (hoffnungsvolj: Nicht doch, sieh’, hier naht Microsoft Excel 
schon. Das bringt Aktion in die Tabellen- 
kalkulation. 

Microsoft Excel: Kompetent, intelligent und exzellent, a 
steh" ich fürs Zahlenmanagement. yon mit Graphik- 
Arbeite heute auf Microsoft und Datenbank- 
WINDOWS 2.0 und 386 - morgen, funktionen - Ma- 
bitte sehr, für den Presentation kroprogrammier- 
Manager. Biete dynamischen Daten- Sprachen - Kon- 
austausch und stehe zur Disposition en un ” 

N rar ey “ ,.. Hilfefunktionen — 

gleichzeitig für viele Tabellen bis hin Computer Based 


zur 3. Dimension. Training - Vor- 
Anwender (beeindruckt): \\nd wie haltet Ihr's mit Applikation? aussetzungen: 
Microsoft Excel; Meine Makros machen mich beweg- WINDOWS 2.0/ 


386, 286/386 


lich und dadurch einfach alles möglich. = 
rozessoren. 


Allerorten - in deutschen und in ganzen 
Worten. 

Anwender (erstaunt): 286/386 Prozessoren? Problembezogene 
Menüs und Dialogboxen? Makrorekorder, ver- 
schiedene Schrifttypen? Ubersetzung von 
Tabellen, Makros und 1-2-3-Befehlen? 

Microsoft Excel: Aber ja, was soll die Frage? Mache jeden 
Auftrag ohne Klage. 

Entscheider (überzeugt): Diese weiten Möglichkeiten, was für Zeiten, was 
für Zeiten. Tabellenkalkulation für jeden Zweck. 
Formatieren, gestalten, drucken, präsentieren. 
Funktionen für Grafik und Datenbank. Gestal- 
tungsmöglichkeiten in Farbe. Fürwahr, fürwahr, 
ich sehe die Entscheidung klar. Schluß jetzt mit 
den Unklarheiten, und auf in neue große Zeiten. 

Microsoft Excel: Die Zukunft ist's, für die ich stehe. Daß Zukunft 
heute schon geschehe. 


Vorhang/Frenetischer Beifall 
ms/nos] [CHT, [me] 6A0/un) 286/386) 


Microsoft 
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couPpoN 
Bitte senden Sie mir Informationsmaterial zu Microsoft Excel. Ich nutze Software: U] privat 
U beruflich/Branche 
Mein Rechner: OD MS-D0OS DIMS-0S/2 U Macintosh 


Bitte senden Sie den Coupon an: Microsoft GmbH - Erdinger Landstraße 2 - BON Aschheim-Dornach 
Absender nicht vergessen. 


Microsoft Symposium 


Es geht Microsoft nicht mehr nur 
darum, gute Standardsoftware zu pro- 
duzieren. Als einziger Komplettan- 
bieter von Betriebssystemen, Netz- 
werklösungen, Entwicklungswerkzeu- 
gen und Standardsoftware wird Micro- 
soft in Zukunft als Systemhaus An- 
wendern bei der Definition und Ent- 
wicklung von Lösungen zur Seite 
stehen. MS OS/2 als herstellerunab- 
hängiges Softwarekonzept macht es 
nötig, daß unabhängige Softwarehäu- 
ser Systemberatung leisten - unabhän- 
gig von der eingesetzten Hardware. In 
diese Rolle will Microsoft hinein- 
wachsen. 

Die Vorstellung von System- und 
Branchenlösungen mit Windows- und 
Excelprodukten war auf diesem Weg 
ein Anfang. Für den Handel ist es 
wichtig zu vermerken, daß dieser 
Anfang gemeinsam mit ihm gesucht 
wird. Denn beim Händler liegt ent- 
scheidendes Knowhow für die System- 
beratung des Endkunden. »Von der 
Kooperation technologisch versierter 
Händler mit Microsoft hängt unser 
beider Erfolg ab.« So lautete denn 
auch die Schlußfolgerung von Dr. 
Jochen Haink, Gesamtvertriebsleiter 
bei Microsoft, vor den autorisierten 
Microsoft-Händlern und -Distribu- 
toren. 

Michael Bülow 


DIE NEUEN MICROSOFT 


COMPILER FÜR 
MS-DOS UND MS-05/2. 


Start frei für Höhenflüge. Die neuen leistungsfähi- 
gen Compiler von MICROSOFT erlauben Ihnen die 


Es ist wirklich nicht schwer, oder? 
Lassen Sie uns sehen, ob Sie es wirk- 
lich verstanden haben. Was wird mit 


Entwicklung professioneller Applika- 


dem folgenden deklariert? 


tionen für MS-DOS und MS-0S/2 - .. Programmgröße 
mit ihnen können unter MS-DOS ent- Gar Sonst vERLADONE:  n 
wickelte Programme problemlos auf _Interprozeß- 
: ; Kommunikation 
MS05/2 poriert werden. Denn Ru Bumisehkeprachli- Als letzte Anregung können Sie 
sind mit allen dafür notwendigen Pro- ches Programmie- sich überlegen, ein Programm zu 
grammierwerkzeugen ausgestattet: ,, Dynamisch inkhare schreiben, das als Eingabe eine C- 
dar kei d _- Biblietheken und Deklaration oder eine deutsche Um- 
R ka eier Programme schreibung erhält, und entweder eine 
mierbaren MICROSOFT EDITOR, dem ., wınDoWS- und Umschreibung oder die entsprechende 
derzeit effizientesten Debugger für die em C-Deklaration liefert. Beachten Sie 
anager-Program- H ä . 
Fehlersuche, MICROSOFT CODEVIEW  mierung mit auch die, Flle, bei Ohnen:aa mehrenn 
- MICROSOFT C Deklaratoren gibt, wie zum Beispiel 

- mit LIB, LINK, MAKE, BIND usw... Mas MundPAscAL 
Aber das ist noch lange nicht alles - " Neue Version des 

ii | | EROEVN OHR 
das Familien-Konzept bringt Sie noch gers: 
einen Schritt weiter in Richt - + unterstützt 
’ SACENIRNN: DRG DIORe Multiple-Thread- Sollte das passieren, dann brechen 
sioneller Programmentwicklung. Alle Programme Sie am besten ab und geben eine ge- 
neuen MICROSOFT COMPILER ent- + unterstützt harnischte Warnung aus, die erklärt, 

: — dynamisch gelinkte daß ich dabei ätnhien P 
halten dieselben Tools. Damit ist es Module a 1 u z “en; = 
& ee ; 5 Konfigurierbarer grammierstil handelt. Viel Vergnügen 
jetzt möglich, gemischtsprachliche Beuel Greg Comeau 
Programme unter einer einheitlichen barer Makro-Editor 
Entwicklungsumgebung zu erstellen: " ginge MARE uni 
von MICROSOFT C 5.1. über MASM 2. nr u 
51, FORTRAN 4.1, BASIC 6.0, für MS-08/2 und 

für MS-DOS 


COBOL 3.0 bis PASCAL 4.0. Und zwar 
unter MS-DOS und MS-0S/2! 


Haben Sie noch Fragen? Dann fragen Sie uns. 
Denn wir haben heute schon die Antwort für 
morgen parat. 


ms/nos) [ms/os/2) (mel 34: 54 


Microsoft 


ZUKUNFT DER SOFTWARE 


couPoN 


Bitte senden Sie mir Informationsmaterial zu: U) MICROSOFT COMPILERN. 
U System Journal, die spezialisiere PC-Fachzeitschrift für Software-Entwicklung 

Ich nutze Software: U] privat UI] beruflich/ Branche 

Mein Rechner: DJ) MS-D008 DI MS-05/2 UI Macintosh 

Bitte senden Sie den Coupon an: Microsoft GmbH - Erdinger Landstraße 2 - 


Absender nicht vergessen. 


8011 Aschheim-Dornach 


SAA-Benutzeroberfläche in C 


"nit einem konstanten Zeichen und einer konstanten”, 
"Farbe gefüllt werden. Neben dem ASCII-Code des Zei-”, 
"chens und der Farbe müssen dabei natürlich auch die”, 
"die Koordinaten der oberen linken und der unteren”, 
"rechten Ecke des angesprochenen Bildschirsbereichs”, 
"angegeben werden.” 
"Wie auch bei allen” anderen Funktionen, die die An-”, 
"gabe eines Bildschirmbereichs erwarten, kann man” 
"sich dabei mit Hilfe der Makros VL(), VO(), vr", 
"und VU() auf die Koordinaten des aktuellen Fensters”, 
"beziehen.”, 
"e" 
}; 
struct vdata df3 = { /* Daten für Demo-Fenster 3 */ 
‚ DFT3, t3, deno3 


/#-- Daten für Demo 4 / 
char *t4[] = /* Text für Demo-Fenster 4 */ 
{ "Ein beliebiger Bildschirmbereich kann mit Hilfe”, 
"der Funktion”, 


“ VioColor()”, 

"eingefärbt werden, ohne daß dadurch die Zeichen”, 
"innerhalb des Bereichs beeinflußt werden.”, 

e"” 


33 


struct vdata df4 = { /* Daten für Demo-Fenster 4 */ 
oe DFR4, DFT4, t4, demo4 


/*-- Daten für Demo 5 “/ 
char *t5[] = Text für Demo-Fenster 5 */ 
{ "Um einen beliebigen Bilschirmbereich kann mit Hilfe”, 
"der Funktion”, 


5 VioFrame()”, 


„ 
"einer von vier verschiedenen Rahaen gezogen werden.”, 
”.” 
}; 
struct vdata df5 = { 


/* Daten für Demo-Fenster 5 */ 
INRA, DFR5, DFT5, t5, demo5 


/*-- Daten für Demo 6 #/ 
char *t6[] = /%* Text für Demo-Fenster 6 */ 
{ ”Zeichenketten können ab einer bestimmten Bildschirm-”, 
„position mit Hilfe der Funktionen", 


n' VioPrint() und VioPrintf”, 


Taisgegeen werden. Während VioPrint() einen einfachen”, 

an I-String auf dem Bildschirm ausgibt, kann der”, 
"Funktion VioPrintf analog zur Funktion printf() ein”, 
„Formatstring und die dazugehörigen Argumente über-", 
„geben werden.”, 
Ser 

}; 

struct vdata df6 = { /* Daten für Demo-Fenster 6 */ 

EINRA, DFR6, DFT6, t6, demo6 


/%*-- Daten für Demo 7 
char *7[] = /* Text für Demo-Fenster 7 */ 


{ "Der Inhalt eines Bildschirmbereichs kann mit Hilfe”, 
„der Funktionen”, 


VioScrollleft(), VioScrollRight(),”, 
VioScrollUp() und VioScrollDown()”, 


"in alle vier Himmelsrichtungen gescrollt werden.”, 
"eo" 


Listing 3: (Fortsetzung) 


/* Daten für Demo-Fenster 7 */ 
EINRA, DFR7, DFT?, t7, demo? 


/*-- Daten für Demo 8 / 
char *t8[] = /* Text für Demo-Fenster 7 %/ 
{ "Das jeweils aktuelle Fenster kann mit Hilfe der”, 
"Funk ionen”, 


VioMoveLeft(), VioMoveRight(),", 
VioMovelp() und VioMoveDown()”, 


"über den Bildschira geschoben und durch den”, 
"Aufruf der Funktion”, 


” VioSetkin()”, 


„ 


"an eine beliebige Bildschirmposition gebracht”, 
„werden.”, 
e"” 


}; 
struct vdata df8 = { 


struct vdata df7 = { 


/* Daten für Demo-Fenster 8 */ 
EINRA, DFRB, DFTS, t8, 8 


/*-- Daten für Verabschiedung 
ng *e[] = 


/ 
/* Text für Verabschiedung */ 


"Auf wiederstarten ... 
nr 
5 


struct vdata dfe = { /* Daten für Demo-Fenster 1 %*/ 
EINRA, DFRE, DFTE, te, (FUP) 8 


; 
struct vdata *demovek[] = { ee bee‘ mit Demo-Beschreibern */ 


‚ &df3, &df4, &df5, 
8dt6, Kam. &df8, &dfe 


REED NEN DENE BIENEN / 


er taste( void ) 


#define TEND ( VioGetCols() - 5 ) /* Endspalte des Textes */ 
#define SPOS ( TEND - sizeof tb ) /* Startposition */ 


static char tb[] = ” bitte Taste betätigen "” 


VioPrint( SPOS, 8, FARBE( MR ), FALSE, "4" ); 
VioPrint( SPOS+1, 8, FARBE( TEC ), FALSE, S ) 
VioPrint( TEND, 8, FARBE( MR ), FALSE, »i" ) 
etch(); /# auf Taste warten */ 
ioPrint( SPOS, 8, FARBE( MR ), FALSE, 
VioStrep( '=', sizeof tb + 1 I) 


#undef TEND /* Konstanten wieder löschen */ 
sr) SPOS 


/' REINE NENNEN NINE NN NENNEN 


* DEMO 2 (Fenster öffnen und wieder schließen) * 
UHR HEHE HEHE HEINE NE HEHE HEHE HEHE NE NEE DE DE DE DENE DE DE DE DENE DE NEE NEED DE DEE IR: / 


ss demo2( void ) 


#define MAX WIN 288 /* anximale Anzahl von Fenstern %*/ 
#define ZUFÄLL(x) ( rand() 8 ((x)+1) ) 


BYTE i = 8, /* Schleifenzähler */ 
veiter, /* TRUE, wenn Fenster geöffnet wurde */ 
sx, Sy, /* Startposition des Fenster */ 
ex, ey, /* Endposition des Fenster */ 
eol; /* Farbe für Rahmen und Fensterinhalt */ 


Listing 3: (Fortsetzung) 
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SAA-Benutzeroberfläche in C 


srand( (int) time( (time_t *%) 8 ) ); /%* Zufallsgen. init. %/ 
ir /* Aufbauschleife */ 


sx = 3 + ZUFALL( VioGetCols()-38 ); /* Startspalte */ 
sy = 3 + ZUFALL( VioGetLines()-18 ); /* Startzeile */ 
ex = sx + 18 + ZUFALL( VioGetCols()- 15 - sx ); 
ey = sy + 3 + ZUFALL( VioGetLines() - 6 - sy ); 
if ( weiter = VioWinOpen( sx, sy, ex, ey ) ) 
{ /* Fenster konnte geöffnet werden */ 
if ( ViolsColor() ) /* Farb-Darstellung möglich? */ 


a = COL( ZUFALL 15 ), ZUFALL( 7 ) ); /" Ja */ 
else 
col = ( ZUFALL( 1 ) ) ? NORMAL : INVERS; 
VioFrame( VL(ß), VO(8), VR(B), vicB). EINRA, col ); 
VioFill( ae un. VR(-1), VUl- 1), 
UFALL(25) + ’A’, col ); 
orrintetine 8), VO(B), Sr TRUE, "1 %3d }”, i+1); 


} 
while (weiter && ++i<MAX_WIN); 
taste(); /* auf Taste warten */ 
0 a /* alle Fenster wieder schließen */ 
ViokinClose( RUE >% 


#undef MAX _WIN 
ser ZUFÄLL 


/* Konstanten wieder löschen */ 


[RBBREBRREBBRRBRBORBRBERGRBBBBBBRRREIRERERERBBIBISEEBEGBRIBEISEIGNEEIENN 


* DEMO 3 (Fenster immer wieder mit Zeichen füllen) * 
HEN NIE EEE NENNEN NENNEN NENNE NEE NE NENNEN RR / 


void demo3( void ) 
BYTE 1; /* Schleifenzähler: */ 


VioHideCursor(); /* Cursor unsichtbar machen */ 
ViokinOpen( 28, 6, 78, 23 ) /* Fenster öffnen */ 
VioFrame( VL), vo(#), ih, Vu(#), EINRA, FARBE( DFRI ) ); 
for (Je "1X rl) 

VioFillt vL(t), vo(t), VR(-1), VU(-1), 1, FARBE( DFRI ) ); 
taste(); /% "auf Taste warten */ 
‚Viokincoset TRUE ); /* Fenster wieder schließen */ 


[PRBERBBBBRBBRRBBBIERRERBBBBBIRBBRBREBIBBNREGEEBNHNHRIREIBERNBEIRENE 


* DENMO4 (Fenster in den verschiedensten Farben einf.) * 
EEE IN II INNEN NINE IE EIERN RR / 


void demo4( void ) 
int 1; /%* Schleifenzähler %/ 


VioHideCursor(); /* Cursor unsichtbar machen */ 
VioWinOpen( 48, 8, 20 ) /* Fenster öffnen */ 
VioFranme( VL(B), vor), YRih), vual: EINRA, FARBE( DFR2 ) ); 
VioFill( VL(1), Ba VR(-1), VUL- 1), ee „ FARBE( DFR2 ) ); 
1X Violscolor() ) /# Farb-Derstellung möglich? */ 
for (i=8; 1<256; ) /* JA, debesı durchlaufen */ 
VioColor( ua), Vo(1), VR(-1), VU(- ı), i++ ); 


else 
for (1-8; i<18; i++) 
VioColor( VL(1), VO(1), VR(-1), VU(-1), NORMAL ); 
VioColor( VL(1), VO(1), VR(-1), VU(-1), UNDERLINE ); 
VioColor( VL(1), VO(1), VR(-1), VU(-1), HNORMAL ); 
VioColor( VL(1), VO(1), VR(-1), VU(-1), INVERS ); 
taste(); /* auf Taste warten */ 
„RREIELLEN TRUE ); /* Fenster wieder schließen *#/ 


[RBBBBBBBHBRRBBBBERBREIBBRBEIBIRRIEREEINEIEIEEENEIEBERIENERRIENEN IE 
* DEMO5 (unterschiedliche Rahmentypen darstellen) * 
REKEN INNE NEE EI EEE ER EBNENEANENERINNAI EA INENER/ 
as demo5( void ) 


BYTE i; 
Listing 3: (Fortsetzung) 
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N ernsreib /* Cursor unsichtbar machen */ 
ViokinOpen( 1, 1, ( VioGetCols() > 1)-1, 

( "VioGetLines() DAT 
VioFrame( VL(8), VO(#), VR(8), VU(8), EINRA, FARBE( DFRI ) ); 
VioClear( VL(1), VO(1), VR(- 1), VU(- 1), FARBE( DFRI ) ); 


VioWinOpen( VioGetCols() >> 1, 1, VioGetCols()-2, 

( VioGetLines() SEEN 1); 
VioFrame( VL(2), VO(8), VR(B), VU(B), DOPRA, FARBE( DFR2 ) ); 
VioGlear( VL(1), VO(t), VR(-1), VUC-1), FARBE( DFR2 ) ); 


VioWinOpen( 1, VioGetLines() >> AD ( VioGetCols() > I) - 1, 
VioGetLines() ER, 

VioFrame(VL(8), VO(8), VR(B), Yin, VOLLRA, FARBE( DFR3 )); 

VioClear( VL(1), vo(1), VR(-1), VWU(-1), FARBE( DFR3 ) ); 


VioWinOpen( VioGetCols() >> 1, VioGetLines() >> 1, 
VioGetCols() - 2, VioGetLines() - 2); 

VioFrame(VL(8), VO(8), VR(), VU(8), PUNKTRA, FARBE DFR4 )); 

VioClear( v1), voct), VR(- ı), vu(-1), FARBE( DFR4 ) ); 


taste(); /* auf Taste warten */ 
for ( i=B; ic4; +i ) 


} VioWinClose( TRUE ); /* Fenster wieder schließen */ 


[PRRRBRRERERBRBBRBRRBRRRRIREHERGBRRGRERRRBREREERRERENINEIENERENENE 


* DEMO 6 (Bildschirmausgaben über VioPrintf) * 
EN RN RE NENEAIEAIEE N ENEENENEEEBINEENEINEINENEENE N NEEIEAEBNENENEIENEEEEE/ 


void demo6( void ) 
#define PI 3.141592654 


BYTE w, /* Winkel %/ 
; /* Schleifenzähler */ 


VioWinOpen( 28, 9, 78, 21 ); /* Fenster öffnen %/ 
VioFrame( VL(B), vo(B), VR(8), VU(®), DOPRA, FARBE( DFRI ) ); 
VioGlear( VL(1), Vo(1), VR(- 1), Vu(- ’), FARBE( DFTI ) ); 


VioPrint( VL(2), VO(2), FARBE( DFT2 ), FALSE, 
TDREeR, über VioPrintf()” ); 
for (i=w=d; i1<7; ++, w+=15) 
VioPrintf( VL(4), VO(4+i1), FARBE( DFT1 ), TRUE, 
"Winkel: %2d°, "Ber %6.48, SIN()=26.4£”, w, 

(float) wPI/188.d, sin( (float) w*P1/188.8 )); 
taste(); /* auf Taste warten %/ 
N eva‘ TRUE ); /* Fenster wieder schließen */ 


[PRBRGRBERBEIRBEIREIEEIRENIEIRRIINGEINENGRIGEIREIRIEIBEIBIEIREIBIRIENRISRIBIRIEIIHRIAEK 


* DEMO? (Inhalt eines Fensters in versch. Richt. ser.) * 
ERORIERIBIAERISEISEIEEIEGEGIEIERNNGRIIRGEREIEBEIBEGERSSGRIEEEEN/ 


yoid demo7( void ) 


static char str[] = "\x88"; 
BYTE 1, j, c; /* Schleifenzähler */ 
BI EDEL), /* Cursor unsichtbar machen */ 
VioWinOpen( 2, 01421234 /* Fenster öffnen */ 
VioFrame(VL(8), os), VR(8), VU(8), VOLLRA, FARBE( DFR? )); 
for ( i=c=1; 1<19; + ) /%* die Zeilen durchlaufen %/ 
nr ( J=1; 75; ++), +str[d] y /* die Spalten durchl. */ 


if ( ++str[8] == ’\8’) /* Zeichen inkrementieren */ 
++str[8]; /* NUL-Zeichen nicht ausgeben */ 
VL(j), VO(i), FARBE( DFT? ), TRUE, str ); 


for ( i=8; i<7 ; +1) 

VioScrollup(VL(1), Vo(2), VR(-1), VU(-1), 1, FARBE( DFT? )); 
taste(); /* auf Taste warten ®/ 
for ( i=8; i<7; + ) 

VioSeroliDown(VL(1), Vo(1),VR(-1),VU(-2),1,FARBE( DFT? )); 

taste(); /* auf Taste warten ®/ 
for ( i=8; i<15 ; +1 ) 

VioScrollLeft(VL(2) ‚VO(1) ‚VR(-1) ‚VUC-1) „1, FARBE( DFT? )); 


Listing 3: (Fortsetzung) 


SAA-Benutzeroberfläche in C 


/* auf Taste warten #/ 4 viodemo( struct vdata * vptr) 


BYTE i, Y k, /* Schleifenzähler */ 
wcol, /* linke lte des Textfensters */ 
wrow; /* ober Zeile des Textfensters */ 


taste(); 
for ( i=8; i<15 ; +1 ) 


„VioSerotiRight(Wt(h), Vo(1),VR(-2),VU(-1),1 N DFT? )); 
taste(); /* auf Taste warten */ 
‚YekinGioset TRUE ); /* Fenster wieder schließen */ 


char **cptr; /%* zum Durchlaufen der einzelnen Textzeilen */ 
/#-- längste Textzeile ernitteln- 


for (i=j=ß, r=vptr->vek; stremp(*cptr, ”e”); ++1, 
Ir U dbestriontahtr))> I /M bibher lumater String? 4/ 
J-k /% Ja, Länge merken */ 


wcol = ( VioGetCols() - j - 4 ) » 1; 

wrow = ( VioGetLines() -i-3) »1; 

VioWinOpen(wcol, wrow, rl wrow++3); 

VioClear( VL(8), VO(ß), VR(8), VU(8), k = FARBE(uptr-»tcol)); 

if ( ng t= KEINRA /* Rahmen ziehen? %*/ 

VioFrame( VL(8), VO(8), VR(8), VU(ß), /# Ja ®/ 
sein. FARBE (vptr-drcol % 


[eRRBRRRBBHBRREBBBRBBIBNBERBIHNNGRINRRERRIEBNNRERIRIIIINEIEREE 
* DEMO 8 (Fenster über den Bildschirm verschieben) y 
EN BD EEE 


void demoß( void ) 


BYTE links, /* Stop links */ 
rechts, /# stop rechts */ 
oben, /* Stop oben */ 
unten, /* Stop unten */ 
xstep; /* Grenzverschiebung in X-Richtung */ 


links = oben = ß; /* Grenzen setzen */ 
rechts = VioGetCols() - 1; 

unten = VioGetLines() - 1; 

xstep = rechts z wem: /"Grenzverschiebung setzen */ 
VioWinOpen( 8, 5, /* Fenster öffnen */ 
VioFrame( Yu "oc, VR(B), VU(8), DOPRA, FARBE( DFR8 ) ); 
VioSetCursor( VL(1), VO(1) ); 

VioFill(VL(1), VO(1), VR(-1), VU(-1), ’\x81’,FARBE( DFTB )); 

we ( Vu(B)&unten && VR(B)<rechts ) 


while ( VU(B) r unten ) /* bereits unten angelangt? */ 
ViolloveDown( 1 );E /® Nein %*/ 
--unten /* Untergrenze dekrementieren */ 
while fi "VR(B) t= rechts ) /® bereits rechts angelangt? */ 
VioMoveRight( 1 ); /* Nein */ 
rechts -= xstep; /%* rechte Grenze dekrementieren */ 
while ( vera = oben ) /* bereits oben angelangt? */ 
Violoveup( 1 % /* Nein #/ 
++oben; /* Obergrenze inkrementieren */ 
while ( VL(B) t= links ) in bereits links angelangt? */ 
VioMoveLeft( 1 ); /* Nein */ 
Sera += xstep; /* linke Grenze inkrementieren */ 


taste(); /* auf Taste warten */ 
Viosetiin 8,8); /* Fenster in obere linke Ecke */ 

te(); /* auf Taste warten %/ 
Viosethint 8, VioGetLines()-6 ); /* untere linke Ecke %*/ 
taste(); /* auf Taste warten */ 
VioSethin( VioGetCols()-11, VioGetLines()-6 hi /* unten r. */ 
taste(); /%* auf Taste warten */ 
Viosethint VioGetCols()-11, 1 ); /* oben rechts */ 
taste /* auf Taste warten */ 
Vieintlose( TRUE ); /* Fenster wieder schließen */ 


for (j=2, cptr=vptr->vek; K Zu ++cptr, ++j) 
„Viohrind VL(2), Vo(j), TRUE, *cptr); 
e 
if ( vptr->fkt t= (FÜP) 8 ) /* Fkt. aufrufen? %*/ 
( EE-SIKt )0; / Ja %/ 
ar nClose( TRUE ); /* das Fenster wieder schließen */ 


[PAARE NENNEN N N NEN NE NENNEN 


* HAUPTPROGRAMM * 
RRRRRBREGGRRERRERBERIBERDDEIEGRIEHEIRIBRRBRRBERSEBRIEIRDIKRRBERDEE/ 


sain() 


static char crstringl[] = 
VIODEMO - (e)° 1988 by Michael Tischer "; 


BYTE i; /%* Schleifenzähler */ 


Violnit(); /* Vio-Modul initialisieren */ 
farbvek = ViolsColor() ? colvek : monovek; /* Farben laden */ 


/*-- gesamten Bildschirm als Fenster öffnen 
ViokinOpen( 8, 8, VioGetCols()-1, VioGetLines()-1 ); 
VioClear( VL(1), vo(1), VR(-1), Vul- 1), Re MB) ); 
VioFrame( VL(ß), VO(8), VR(8), VU(B), ‚„ FARBE( MR ) ); 
VioPrint( VLLLVCOL - sizeof erstring) >» ), vuß), 

FARBE( CRI ), FALSE, crstring ); 


/%#-- die einzelnen Demos ausführen 

for (i=8; i< (sizeof demovek / sizeof(struct vdata *)); ++) 
viodemo( demovek[ i ] ); 

9a ee NN NENNEN NENNEN 
JRISIaeR! TRUE ); /* Haupt-Fenster wieder schliepen */ 


* VIODENO * 
FRRHRBRRRRRRBRBBRHRRRERBGRBRERRREBEERERRBRRRHREBBBIBBRIRBRERKEEN/ 


Listing 3: (Fortsetzung) Listing 3: (Ende) 
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Komplexe C-Deklarationen verständlich gemacht 


Die Sprache C gibt es jetzt schon seit etlichen 
Jahren, aber viele Teile ihrer Syntax werden 
sogar von guten Programmierern noch immer 
nicht verstanden. Der Grund dafür ist das Feh- 
len einer einheitlichen Dokumentation, die alle 
Möglichkeiten, im besonderen auch Zeiger, 
behandelt, die in der Sprache verfügbar sind, 
einschließlich der Erweiterungen des American 
National Standards Instituts und von Microsoft. 


Solange diese Neuerungen nicht klar oder sogar falsch ver- 
standen werden, nützen Programmierer die Sprache C 
unglücklicherweise nicht voll aus. Statt dessen werden 
(sogar von sehr guten Programmierern) Programme 
geschrieben, die unnötig kompliziert und manchmal sogar 
nicht ganz korrekt sind. Der Zweck dieses Artikels ist es, 
einige typische Eigenschaften von C-Deklarationen, die 
sowohl Anfänger als auch Experten verwirren, klarzustellen. 
Sehen wir uns am Anfang eine Deklaration an, die viele C- 
Programmierer für schwerverständlich halten: 


struct vtag far * (far * const far var [5])(); 


Wenn Sie auf Anhieb verstehen, was diese Deklaration 
bedeutet, springen Sie gleich zum Ende des Artikels und 
bearbeiten die Deklarationen am Ende zur Übung. Wenn 
Sie soweit sind, wie ich noch vor kurzer Zeit war, das heißt, 
Sie denken, daß Sie es verstehen, sind sich aber nicht sicher, 
dann sollten Sie weitermachen. Sie werden in der Lage sein, 
C-Deklarationen wie die vorstehende zu lesen und zu 
gebrauchen, Sie werden sogar das Lesen und Schreiben von 
C-Deklarationen anderen erklären können. Nur dann kön- 
nen Sie die volle Leistungsfähigkeit der Sprache voll nutzen. 


Deklarationssyntax 


Um eine Sprache zu benutzen, müssen Sie etwas über die 
Struktur und Syntax wissen. Zuerst müssen Sie beim Lesen 
einer C-Deklaration feststellen wie sie organisiert ist. Inner- 
halb der vorgegebenen Anordnung einer Deklaration kön- 
nen verschiedene Attribute angegeben werden. Abhängig 
von den verwendeten Attributen kann der Typ des Bezeich- 
ners festgestellt werden. Die Syntax für die explizite Dekla- 
ration von Bezeichnern in C ist in Abbildung 1 dargestellt. 

Eine Deklaration kann viele Angaben aus Abbildung 1 
enthalten, aber sie muß mindestens einen Typ und einen 
Deklarator enthalten. Beachten Sie, daß einige Compiler 
die Angabe eines Bezeichners nur außerhalb einer Funktion 
akzeptieren; C-Programmierer sollten diese Codierpraxis 
meiden, da es schlechter Programmierstil ist, zu Fehlern 
führen kann und bei der Wartung Probleme auftreten kön- 
nen. Darüber hinaus ist diese Praxis durch die bevorste- 
hende ANSI-Normung veraltet. 
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Die Syntax einer C-Deklaration lautet: 


Speicherklasse Typ Qualifizierer Deklarator = Initialisierung; 


Wobei Speicherklasse folgendes sein kann: 
typedef 
extern 
static 
auto 
register 


Typ kann eines oder mehrere dieser Schlüsselwörter sein: 
void 
char 
short, int, long 
float, double 
signed, unsigned 
struct .. 
union ... 
typedef type 


Ein Deklarator enthält einen Bezeichner und einen oder 
mehrere, oder auch keine der folgenden Zeichen in einer 
Vielzahl von Kombinationen: 


* 


() 
Eventuell sind diese geklammert, um unterschiedliche 
Bindungen auszudrücken. 


Abbildung 1: Die Standardsyntax für C-Deklarationen 


Deklarationen: Theorie 


Viele von uns können Deklarationen wie die folgenden 
lesen: 


Dank Brian W. Kernighan und Dennis M. Ritchie und 
ihrem Buch »The C Programming Language« (Prentice- 
Hall, Inc. 1978) - oder K&R, wie ich es von jetzt an nenne - 
können wir sogar noch folgende verstehen: 


int *ial3]; 


int (*a)[3]; 


Bisher haben wir uns dies einfach gemerkt. Zu unserem 
Glück deckt dies 85% der vorkommenden Deklarationen 
ab. Das Verständnis der restlichen 15% bereitet jedoch 
größere Schwierigkeiten. 


1. Klammern Sie Deklarationen so, als ob es Ausdrücke 
wären. 

2. Suchen Sie die innerste Klammer. 

3. Sagen Sie »Bezeichner ist«, wobei Bezeichner der Name 
der Variablen ist. 
Sagen Sie »ein Array von X« wenn Sie [X] sehen. 
Sagen Sie »Zeiger auf« wenn Sie * sehen. 

. Gehen Sie zur nächsten Klammerebene. 

. Wenn es weiter geht, machen Sie bei 3 weiter. 

. Sonst sagen Sie »Typ« für den verbleibenden Typ auf 
der linken Seite (wie zum Beispiel short int). 


au» 


Abbildung 2: Regeln zum Lesen und Schreiben von K&R- 
Deklarationen 


Vielen Programmieren fehlt das Verständnis für kom- 
plexe Deklarationen und die Benutzung der damit dekla- 
rierten Bezeichner. Wegen schlechter Dokumentationen ist 
für gewöhnlich Raten der einzige Ausweg. Über kurz oder 
lang werden Sie auf den Bauch fallen, da das Raten zu Ver- 
allgemeinerungen führt, die nicht notwendigerweise richtig 
sind. Auch wenn Sie dem Sinn sehr nahe kommen, kann der 
vom Compiler erzeugte Code unter Umständen stark vom 
Gewünschten abweichen. 

Ich wünschte, das Rätselraten wäre mir erspart geblie- 
ben, als ich C lernte. Das ist um so trauriger, da die Theorie 
von Deklarationen sehr einfach ist. Sie brauchen nur wissen, 
daß Deklarationen auf der Hierarchie der C-Operatoren 
beruhen, derselben, die Sie auch beim Erstellen von Aus- 
drücken benutzen. Im Fall der Deklarationen bedeutet dies 


für die Auswertungsreihenfolge: 
() oder [] haben höchste Priorität, Aus- 
wertung von links nach rechts 
* hat niedrigste Priorität 


wobei Klammerung die normalen Vorrangregeln ändert. 
Das ist schon alles. Mit diesem Wissen brauchen wir nur 
noch Regeln zu formulieren, so wie sie in Abbildung 2 vor- 
geschlagen werden. 

Lassen Sie uns einige Beispieldeklarationen durch- 
machen. Benutzen wir die Seite 200 von K&R als Referenz, 
um die in Abbildung 3 dargestellten Deklarationen zu stu- 
dieren. Diese sind entsprechend der Vorrangregel-Tabelle 
der Sprache C geklammert. 

Wenn eine Deklaration einmal geklammert ist, besteht 
die Entzifferung lediglich darin, zu sagen, was jeder 
geklammerte Ausdruck bedeutet. Dies gleicht der Klamme- 
rung von arithmetischen Ausdrücken, bei denen eine 
bestimmte Addition Vorrang vor einer bestimmten Multi- 
plikation haben kann. Die einzige Schwierigkeit besteht 
darin, daß Multiplikation und Division binäre Operatoren 
sind (sie arbeiten mit zwei Operanden), wogegen wir es mit 
unären Operatoren zu tun haben, die nur einen Operanden 
benötigen. 


*; 
ri 
v 
1 ist 
v 


ein Zeiger auf 


v 
eine Integer 


*1[3]; 
Ne ng 


v 
i ist ein Array von 3 


v 
Zeigern auf 


(*1)[3]; 
ad 


v 
1 ist 
v 
ein Zeiger auf ein Array von 3 


i ist eine Funktion mit dem Rückgabewert 


v 
Zeiger auf 


Abbildung 3: Die Interpretation von Deklarationen durch 
Klammerung 


Beachten Sie, daß jede geklammerte Deklaration in 
Abbildung 3 auch syntaktisch eine gültige Deklaration ist. 
Sie werden nicht nur wegen ihrer gleichen Bedeutung 


gezeigt. 
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1. Gegeben: Nicht terminierende Attribute sind [], () 


und *, also Arrays, Funktionen, und Zeiger. 


2. Beachten Sie die Rechts-nach-links-Regel: Schauen Sie 
nach rechts (innerhalb der Klammern), nehmen Sie das 
Attribut, falls vorhanden, schauen Sie dann nach links, 
und nehmen, falls vorhanden, dieses Attribut. 


3. Das Übersetzen einer C-Deklaration ins Deutsche: 
a. Stellen Sie den Bezeichner der Deklaration fest. 
Sagen Sie »Bezeichner ist« wobei der Bezeichner der 
Name der Variablen ist. 
b. Schauen Sie rechts vom Bezeichner nach den Attri- 
buten () oder []. Bedenken Sie: Es kann auch keines 
vorhanden sein. 
Sagen Sie »ein Array von« wenn Sie [] sehen. 
Sagen Sie »ein Array von x« für alle [x], die Sie sehen. 
Sagen Sie »ein x-mal-y Array von« wenn Sie [x][y] 
sehen. 
Sagen Sie »ein x-mal-y mal ... Array von« wenn Sie 
[x]J[y][:..] sehen. 
Sagen Sie »Funktion mit Rückgabewert« für ( ), wenn 
das zuletzt gefundene rechte Attribut [] war. 
Sagen Sie »eine Funktion mit Rückgabewert« für ( ). 
c. Schauen Sie jetzt auf die linke Seite des Bezeich- 
ners (wegen der Rechts-nach-links-Regel), und schauen 
Sie nach weiteren Attributen. Es kümmern uns hier nur 
Sterne; alles andere wäre ein Fehler. Denken Sie daran, 
daß hier auch nichts stehen kann. Beachten Sie auch die 
Klammern. Für jedes * sagen Sie »Zeiger auf«, wenn 
das zuletzt rechts gefundene Attribut [] war und das 
jetzige Attribut * ist, andernfalls sagen Sie »ein Zeiger 
auf«, wenn Sie * sehen. 
d. Schauen Sie wieder rechts nach Attributen. Hier 
können auch keine sein. Seien Sie hier vorsichtig mit 
Klammern. Falls dort welche stehen, gehen Sie zurück 
nach b. 
e. Es sollte ein terminierendes Attribut wie eines der 
folgenden übrigbleiben: char, int, short, long, 
float, double, struct, union, und/oder einer ihrer 
Modifizierer signed, unsigned, static, register, 
und extern. 


Abbildung 4: Lesen und Schreiben von K&R-Deklarationen 


Deklaration: Anwendung 


Obwohl die in Abbildung 1 gezeigten Regeln einfach sind, 
besteht ihr Nachteil darin, daß Sie sich hinsetzen und die 
Deklarationen klammern müssen. Statt die Zeit mit der 
Klammerung von »Unterdeklarationen« zu verschwenden, 
wäre es hilfreicher, die Theorie zu etwas Nützlicherem zu 
verallgemeinern. Die Regeln in Abbildung 4, Teile 1, 2, 3 
und 5, erlauben Ihnen, Deklarationen im Fluge zu lesen. 
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Sagen Sie »Struktur vom Typ y« für struct y. 

Sagen Sie »Union vom Typ y« für union y. 

Sagen Sie »Attribut« und lesen Sie von links nach rechts 
(wörtlich) die terminierenden Attribute. 


4. Regeln zum Umsetzen vom Deutschen in C-Deklaratio- 
nen: 
a. Schreiben Sie »Bezeichner«, wobei Bezeichner der 
Name der Variablen ist. 
b. Wir müssen uns mit einem Flag merken, ob das 
letzte Attribut bei der Verarbeitung ein Stern war. Wir 
wollen unser Flag »Aktiver-*« nennen und es zu Beginn 
auf 0 setzen. 
c. Schreiben Sie * zur linken dessen was dasteht, so- 
lange Sie in der Beschreibung »Zeiger auf« sehen. Set- 
zen Sie Aktiver-* = 1 (merken, daß das letzte Attribut 
ein Stern war). 
d. Schreiben Sie (bisher_aufgeschriebene_At- 
tribute ) wenn Aktiver-*=1. 
Schreiben Sie [x] rechts, wenn Sie »Array von x« sehen. 
Schreiben Sie [x][y]- . . rechts, wenn Sie »ein x-mal-y 
... Array von« sehen. 
Schreiben Sie [] rechts, wenn Sie »Array von« sehen. 
Schreiben Sie ( ) rechts, wenn Sie »Funktion mit Rück- 
gabewert« schen. 
e. Machen Sie mit b weiter, wenn noch weitere nicht 
terminierende Attribute vorhanden sind. 
f. Schreiben Sie einfaches Attribut links von 
allem, wobei das einfache Attribut eines oder eine 
Kombination der terminierenden Schlüsselwörter ist, die 
in Abbildung 1 gezeigt wurden. 
Schreiben Sie ; rechts von allem. 

5. Anmerkungen: 
a. Sie können kein Array von Funktionen haben. Sie 
können aber ein Array von Zeigern auf Funktionen 
haben. Die Deklaration int a[5]() ist ungültig. 
b. Eine Funktion kann kein Array zurückliefern. Eine 
Funktion kann aber einen Zeiger auf ein Array liefern. 
Die Deklaration int a( )[] ist ungültig. 
c. Eine Funktion kann keine andere Funktion als Er- 
gebnis liefern, sondern nur einen Zeiger darauf, was be- 
deutet, daß int a( )( ) ungültig ist. 


Auf den ersten Blick scheint es, daß die Regeln 
komplexer sind, als die in Abbildung 1, aber es sind nur 
erweiterte Versionen dieser Regeln. 

Nach der Bearbeitung einiger einfacher Deklarationen 
werden Sie sehen, wie natürlich diese Regeln sind. Sie sind 
nahezu identisch mit denen in Abbildung 1, da wir aber die 
Priorität der Operatoren kennen, ist es überflüssig, sie zu 
klammern. Wenn wir die Beispiele aus Abbildung 3 
nehmen, kommen wir zu den Ergebnissen in Abbildung 5. 


int i 

| 

v 
i ist 

v 

eine Integer 


int ”; 


v 

1 ist 

V. 
ein Zeiger auf (rechts steht nichts mehr, daher 
schauen wir nach links) 

rv 
eine Integer (es bleibt nur ein terminierendes 


Attribut links) 


int is 


v 
i ist ein Array von 3 (schauen Sie zuerst rechts) 


int fi 


v 

i ist 
v 

ein Zeiger auf 
v 


einen Zeiger auf 
v 


eine Integer 


int on 


v 
1 ist 
v 


ein Zeiger auf 
eine Funktion 
mit Rückgabewert 


v 
Zeiger auf 


(rechts keine weiteren Attribute, 
links ein *) 


(links noch ein *) 


(rechts keine weiteren Attribute, 
links ein *) 

(Ende der Klammerung, 

rechts ist ()) 


(rechts keine weiteren Attribute 
versuchen wir es links) 


v 
Zeiger auf 


v 
Integer 


int ran 


v 
i ist 
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ein Zeiger auf 
ein Array von 3 


v 
Integern 


int ni 


v 


i ist eine Funktion 


mit Rückgabewert 
v 
Zeiger auf 


v 
Integer 


int en 


v 
i ist 
v 


ein Zeiger auf 
eine Funktion 
mit Rückgabewert 


v 
Integer 


(keine weiteren Attribute rechts, 
daher schauen wir nach links) 


(es bleibt nur ein terminierendes 


Attribut links) 


(Klammern gefunden - rechts ist 
nichts, links ist ein *) 
(Klammerattribut abgeschlossen, 
schauen Sie nach rechts) 


(es bleibt nur ein terminierendes 
Attribut links) 


(rechts () gefunden) 


(rechts ist nichts mehr, links 
bleibt ein *) 


(es bleibt nur ein terminierendes 
Attribut links) 


(* ist innerhalb der Klammern) 


(() ist das Attribut rechts 
der Klammerung) 


(es bleibt nur ein terminierendes 
Attribut links) 


Abbildung 5: Interpretation von Deklarationen nach Regeln 


v 
Integer 


int re 


v 

i ist ein Array von (bleiben wir innerhalb der 
Klammern, schauen wir nach 
rechts) 


(jetzt links) 
(Ende der Klammerung 
Jetzt Blick nach rechts) 


v 

Zeigern auf 

Funktionen mit 

Rückgabewert 
v 


Zeiger auf 


r 
Integer 


Abbildung 6: Interpretation von Deklarationen nach Regeln 


Erzeugen wir einige Abkömmlinge der Deklarationen 
von K&R, erhalten wir die in Abbildung 6 gezeigten. Benut- 
zen wir Abkömmlinge der Beispiele der Language Reference 
des Microsoft C-Compilers Version 5.0, so erhalten wir die 
in Abbildung 7 gezeigte. Wir wissen, daß diese Deklaration 
sich von der folgenden unterscheiden muß: 


char *(*(abe()))[L18] 


Hier ist abc eine Funktion, die einen Zeiger auf einen 
Zeiger auf ein Array von 10 Zeigern auf char liefert, die 
auch so geschrieben werden kann: 


char *(**abc())[L10] 


Zu guter Letzt zeigt Abbildung 8 ein Beispiel einer 
union-Deklaration. 
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char 


rund 


v 
1 ist 
Sa Zeiger auf eine Funktion mit Rückgabevert 
Gr auf ein Array mit 18 
Zeiger auf 


Abbildung 7: Interpretation von Deklarationen nach Regeln 


Schreiben von Deklarationen 


Die Regeln zum Schreiben von Deklarationen auf der Basis 
von deutschen Beschreibungen ist ebenso einfach, da es 
genauso wie das bisher Gesagte funktioniert, nur umge- 
kehrt. Die Teile 1, 2, 4 und 5 der Abbildung 4 zeigen die zu- 
gehörigen Regeln. Die Beispiele in den Abbildungen 5, 6, 7 
und 8 sind in umgekehrter Notation in Abb. 9 dargestellt. 


ANSI-Erweiterungen 


Das X3J11-Komitee des ANSI-Instituts hat die K&R-Defi- 
nition von C um Schlüsselworte und Nomenklaturen (wie 
Funktionsprototypen, die wir hier nicht besprechen) erwei- 
tert (Abbildung 10). 

Die Schlüsselworte, die wir hier besprechen, sind const 
und volatile. Der Typenqualifizierer const gibt an, daß 
sich das mit dem Typ verbundene Objekt nicht verändert, 
das heißt, es wird ihm nichts zugewiesen und es wird nicht 
inkrementiert oder dekrementiert. Der Typenqualifizierer 
volatile gibt an, daß das Objekt entsprechend der C- 
Ausdrucksbewertung ausgewertet werden muß, was garan- 
tiert, daß C-Anweisungen und Objekte, die von diesen 
Anweisungen verwendet werden, einer vorgegebenen Aus- 
führungsreihenfolge unterliegen. Da die Reihenfolge der 
Auswertung oftmals viele Optimierungen unmöglich macht, 
kann ein volatile-Objekt von einem anderen Programm 
als dem »besitzenden« verändert werden, ohne Furcht vor 
Inkonsistenz. 

Einige Punkte zu diesen Schlüsselworten, die zu beach- 
ten sind: 
= Einer const-Variablen kann kein Wert zugewiesen 

werden. 
= Eine const-Variable, die nicht volatile ist, kann im 

ROM plaziert werden. 
= Eine volatile-Variable kann durch Dinge wie DMA, 

asynchrone Prozesse oder gemeinsamen Speicher ver- 

ändert werden. 

= Eine volatile-Variable kann nicht wegoptimiert wer- 
den - das System muß der abstrakten C-Maschine fol- 
gen, soweit es diese Bezeichner betrifft. 
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union sign *(*1[5])[5]; 


v 
i ist ein Array von 5 


igern auf ein Array von 5 
Zeigern auf 


v 
union sign 


Abbildung 8: Interpretation von Deklarationen nach Regeln 


= Ein Objekt ohne diese Attribute, das heißt, ein unquali- 
fiziertes Objekt, kann ausgelesen oder beschrieben wer- 
den, ohne Zerstörung irgendwelcher Art, außer syn- 
chron durch ein anderes Objekt, wie etwa einen Zeiger. 


Um diese Schlüsselworte besser zu verstehen, schauen 
wir uns ein praktisches Beispiel an. Ein ausgezeichnetes 
Beispiel aus dem vorgeschlagenen Standard ist die Dekla- 
ration eines Eingabeports im Arbeitsspeicher, der zu einer 
Echtzeituhr gehört. Dies sieht dann so aus: 


extern const volatile int real_time_clock; 


Hier wird ein Integerwert deklariert, der vom Programm 
nicht verändert werden kann (const), aber von einem 
externen Ereignis (volatile), nämlich der Uhr. 

Nachdem wir wissen, was diese Schlüsselworte bewir- 
ken, müssen wir ihre Verwendung in unsere Regeln ein- 
bauen. Ein Anhang zu unseren bisherigen Regeln wird in 
Abbildung 11 gezeigt. Daraus folgt, daß Typenqualifizierer 
den Typ des Objekt ändern, egal, ob es sich um einen Basis- 
typ, oder um einen Zeigertyp handelt. So wird in der Dekla- 
ration 


const int 1; 


i als Integerwert definiert, der nicht geändert werden 
kann und wird. In einer solchen Situation, kann i jedoch bei 
der Definition initialisiert werden, da es ein Fehler wäre, 
später einen Wert zuzuweisen. Es ist wichtig zu verstehen, 
daß const ändert, was man mit i machen kann, doch es 
verändert nichts direkt am Basistyp; dies gilt für alle Quali- 
fizierer. Eine Analogie dazu ist, daß das Streichen eines 
großen grünen Hauses in einer anderen Farbe (ändern 
einer Characteristik) nicht die Größe des Hauses oder die 
Tatsache, daß es ein Haus ist, ändert. z 

Neben der Änderung eines Bezeichners oder Objekts 
könne Qualifizierer auch Zeiger ändern. Sie sollten verste- 
hen, wie Sie einen so geänderten Zeiger codieren müssen, 
was wahrscheinlich der schwierigste Aspekt beim Lesen von 
Deklarationen ist. 


i ist — eine Integer 
v 
H } 
int 1; 
1ist — a Zeiger — auf eine Integer 


v 
int *1; 
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v 
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* v 
0) Y 
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v 
*“ | 
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i ist ein Zeiger — Ir eine Funktion mit Rückgabewert —> Zeiger —> auf eine Integer 
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*i r 
0) v 
*)e) v 
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Zeigern 
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]r 
char *(*(*i)())[18]; 


1 ist ein Array —> von 5 Zeigern —+ auf Arrays mit 5 —> union sign 
[ Zeigern auf 


10 


r 
1[5] 
*1[5] 


v 
union sign *(*1[5J)L[]; 


Abbildung 9: Die Ableitung von Deklarationen aus deutschen Beschreibungen 
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Die Syntax einer C-Deklaration wird von der angekündigten 
ANSI-Norm folgendermaßen festgelegt: 


Speicherklasse Typ Qualifizierer Deklarator = Initialisierung; 


Zusätzliche neue Qualifizierer können einer oder mehrere 
der folgenden sein: 

const 

volatile 


Zusätzliche neue Typen können einer der folgenden sein: 
void 
signed char 
unsigned char 
unsigned int 
unsigned long 
long double 
enum . 


Abbildung 10: ANSI-Erweiterungen 
Wird zum Beispiel ein konstanter Zeiger als 


int const *p 


oder als 


int *const p 


geschrieben? 

Wenn int *p besagt, daß p ein Zeiger auf int ist, 
dann besagt int const *p, daß p ein Zeiger auf einen 
konstanten Integerwert ist. Da p also ein Zeiger auf eine 
Konstante ist, muß es also Konstantenzeiger sein, oder? 
Vielleicht. Da bei int * const p p selbst eine Konstante 
ist, die ein Zeiger auf int ist, ist es also ebenfalls ein Kon- 
stantenzeiger, oder? 

Es kann nur eines von beiden stimmen. Wir wollen dies 
im Detail besprechen, da uns ein ähnliches Problem später 
wieder begegnet, wenn wir die Microsoft-Erweiterungen 
(near und far) besprechen. Es geht darum, den Unter- 
schied zwischen einem »konstanten Zeiger« und einem 
»const-Zeiger« zu verstehen. Obwohl der Unterschied nur 
gering ist, wird dadurch eine Mehrdeutigkeit aufgelöst, die 
auftritt, wenn verallgemeinernde Ausdrücke wie »Konstan- 
tenzeiger« gebraucht werden. 

Der Unterschied ist, daß ein konstanter Zeiger sich 
nicht ändert; er ist konstant, ein Zeiger, dessen Wert sich 
nicht ändern kann. Zeiger die nicht konstant sind, sind 
variabel. Andererseits ist ein const-Zeiger (const *) ein 
Zeiger auf eine Konstante eines bestimmten Typs. Beachten 
Sie das Wort »konstant« im einen Fall und das Schlüssel- 
wort const im anderen; sie sind nicht gleich. 
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Das Lesen und Schreiben von ANSI-Deklarationen gleicht 
dem Lesen und Schreiben von K&R-Deklarationen. Man 
muß jedoch einige zusätzliche Dinge beachten, da einige 
Typenqualifizierer hinzugefügt wurden. Dabei handelt es 
sich um folgendes: 


1. Beim Vorschlag der Erweiterungen zu den Regeln in 
Abbildung 4 geht es uns darum, daß die ANSI-Erweite- 
rungen Schlüsselwörter sind und nicht notwendigerweise 
Vorrangregeln gehorchen. Schlüsselwörter an sich 
folgen keinen konsistenten Mustern. 

2. Unabhängig von anderen Typenspezifikationen hat jeder 
Qualifizierer (const, volatile) einen entsprechenden 
Zeigerttyp (const *, volatile *). 

3. Bei einer fehlenden Typenspezifikation wird int ange- 
nommen, const x bedeutet zum Beispiel int const x. 
Hierbei handelt es sich jedoch um veralteten Stil. 

4. Typenqualifizierer und Typenspezifikationen können 
ohne Rücksicht auf die Reihenfolge vermischt werden. 
Der jeweilige Ergebnistyp wird dadurch nicht verändert, 
const int var und int const var sind beispiels- 
weise gleich. 

5. Die Vermischung von Typenqualifizierern mit Deklara- 
toren (der Teil einer Deklaration, der den Bezeichner 
und die Attribute Funktion, Array und Zeiger angibt) 
verändert die Bedeutung der Deklaration. Die Bindung 
von Qualifizierern ändert sich also in Abhängigkeit vom 
Kontext. 

6. Zur Verdeutlichung von 4. und 5. und um einen Fall wie 
const int * p klarzustellen, müssen wir folgendes 
vorschlagen: Typenqualifizierer verändern den Typ eines 
Deklarators. Im Fall einer Deklaration mit Zeigern wie 
bei Typ * Typenqualifizierer Deklarator (zum Beispiel 
int * const var) wird gesprochen Deklarator Quali- 
fizierer Zeiger auf Typ (var ist ein konstanter Zeiger auf 
eine Integer). 

7. Nicht qualifizierende Deklarationen (die mit der Stan- 
dardqualifizierung) können so gelesen werden. Kein 
const bedeutet also variabel und kein volatile nicht 
volatile. Es wird empfohlen, die Standardqualifizie- 
rer zu einem Bezeichner hinzuzufügen, auch wenn die 
Standardqualifizierung kein Schlüsselwort ist. 


Abbildung 11: Lesen und Schreiben von ANSI-Deklaratio- 
nen 


Zur Verdeutlichung hier einige Beispiele: 


i ist eine variable Integer. Ihr können verschiedene 
Werte zugewiesen werden. 


Microsoft C 


const int i; 


int %p; 
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p ist ein variabler Zeiger auf eine variable Integer; so- 
wohl p als auch der Integer, auf die der Zeiger zeigt, kön- 
nen Werte zugewiesen werden. 


int * const p; 
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er zeigt, kann verändert werden. 
const int *p; 


zeigt, aber nicht. 


int const *p; 


also dasselbe wie const int *p. 


const int * const p; 


p ist ein konstanter Zeiger auf eine konstante Integer; 
weder der Zeiger p noch die Integer, auf die er zeigt, 


p ist ein variabler Zeiger auf eine konstante Integer. 
Dies bestätigt const int *p und int const *p, denn 


nach der ANSI-Norm als schlechte Programmierweise 
angesehen wird, denn es führt zu Schludrigkeiten bei der 
Codierung von Deklarationen. 

Gerüstet mit diesem Wissen, können Sie nun einige 


wort volatile nur syntaktisch, nicht semantisch. Wir wer- 
den auch das sogenannte Variabel-Attribut weglassen, da es 
nur dem Verständnis diente. 


const int 1; 


i ist eine konstante Integer. 


const int %i; 


i ist ein Zeiger auf eine konstante Integer. 


int %* const i; 


i ist ein konstanter Zeiger auf eine Integer. 


const int * const 1; 


i ist ein konstanter Zeiger auf eine konstante Integer. 


const int *i[3]; 


i ist ein Array von 3 Zeigern auf konstante Integer. 


int * const i [3]; 


i ist ein Array von 3 konstanten Zeigern auf Integer. 


const int * const i[3]; 


i ist ein Array von 3 konstanten Zeigern auf konstante 
Integer. 


const int (*1)[3]; 


i ist ein Zeiger auf ein Array von 3 konstanten Integern. 


int (* const 1)[3]; 


i ist ein konstanter Zeiger auf ein Array von 3 Integern. 


int (const * 1)[3]; 
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const int (const * const 1)[3]; 
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Dies ist aus dem gleichen Grund ein Fehler. 
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ten Integern. 
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const int *i(); 
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Compiler ein Meldung ausgeben muß. Die ANSI-Norm 
definiert dies jedoch als »undefiniertes Verhalten«. Auf den 
ersten Blick scheint die Qualifizierung von Funktionstypen 
unsinnig zu sein, es kann jedoch dafür verwendet werden, 
eine Funktion im ROM zu plazieren. 


const int (*#)(); 
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int (* const i)(); 
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Dies ist ein Fehler, da das Schlüsselwort const nicht 
unmittelbar auf eine sich öffnende Klammer folgen kann. 


const int %1; 


i ist ein Zeiger auf einen Zeiger auf eine konstante 
Integer. 
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Integer. 


int * const * 1; 
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int const * const * i; 


i ist ein Zeiger auf einen konstanten Zeiger auf eine 
konstante Integer. 


const int const * const * 1; 


Dies ist ein Syntaxfehler, da die ersten beiden const- 
Schlüsselworte zum Typ gehören und nicht zum ersten 
Stern. 


const int * const * const * i; 


i ist ein konstanter Zeiger auf einen konstanten Zeiger 
auf eine konstante Integer. 

Sie werden in den obigen Beschreibungen, besonders bei 
const int *i[3], int * const i[3] und const 
int * const i [3], bemerkt haben, daß es hier nicht 
»konstantes Array«, sondern »Array von Konstanten« heißt. 
Das soll kurz erklärt werden. 

Wenn beim Parsen einer Deklaration der letzte Typ ein 
Array ist und der aktuelle Typ ein Qualifizierer, so bezieht 
sich der Qualifizierer auf den Datentyp des Arrays, und 
nicht auf das Array selbst. Das macht Sinn, wenn Sie sich 
einige Ungereimtheiten von Arraytypen und Arrays vor 
Augen halten; besonders da ein Array nur eine Adresse 
repräsentiert und darüber hinaus nicht viele andere Attri- 
bute hat, da die Adresse einfach nur eine Speicherstelle ist. 
Tatsächlich wollen wir ja auch den Arrayelementen das 
Attribut const geben, da ihnen nichts zugewiesen werden 
soll. Zusätzlich sollten Sie bedenken, daß eine Arrayver- 
wendung ebenso eine Konstante ist. 


Microsoft-Erweiterungen 


Ebenso wie ANSI hat es auch Microsoft für notwendig 
gehalten, die Sprache C um einige zusätzliche Schlüssel- 
worte zu erweitern (Abbildung 12). Vier von ihnen sind 
Attribute von Funktionen. 

Die ersten drei (cdecl, pascal und fortran) werden 
in Verbindung mit Funktionen in anderen Sprachen benö- 
tigt (BASIC, FORTRAN, MASM oder Pascal) oder ermög- 
lichen den Aufruf von C-Funktionen aus diesen Sprachen. 
Diese speziellen Schlüsselworte sind eigentlich Compiler- 
anweisungen, die diesen veranlassen, speziellen Code zu 
erzeugen, so daß die übergebenen Parameter so behandelt 
werden, als ob sie in der Sprache geschrieben worden 
wären, die in der aufgerufenen Funktion verwendet wird. 

Um eine C-Funktion zu deklarieren, die in Pascal ge- 
schrieben sein könnte, würden Sie folgendes verwenden: 


extern int pascal func(long, int), 


Microsoft C 


Microsoft hat die K&R- und ANSI-Definitionen um zwei 
zusätzliche Schlüsselwörter im Bereich der Qualifizierer 
erweitert: 

far 

near 

huge 

cdecl 

pascal 

fortran 

interrupt 


Abbildung 12: Microsoft-Erweiterungen 


Ein Zeiger auf diese Funktion könnte so aussehen: 


int (pascal *fp)(long, int); 


Das Schlüsselwort interrupt ist auch eine Compiler- 
anweisung, die diesen veranlaßt, speziellen Code zu erzeu- 
gen. In diesem Fall wird Code erzeugt, um die Funktion 
mittels eines Interrupts aufrufen zu können. 

Die drei anderen Schlüsselworte near, far und huge 
werden zur Adressierung eines Objekts auf Prozessoren mit 
segmentierter Architektur verwendet, wie die von Intel. 
Diese Schlüsselworte, und insbesondere far, werden oft bei 
der Programmierung in einem für diese Architektur typi- 
schen gemischten Speichermodell benötigt. 

Microsoft behandelt die speziellen Schlüsselworte wie 
Deklaratorqualifizierer (nicht Deklarationsqualifizierer), 
das heißt, sie können nur syntaktische Einheiten auf der 
rechten Seite der Deklaration ändern, nicht aber den Basis- 
typ, wie zum Beispiel int, direkt. Das Microsoft-C-Hand- 
buch gibt an, daß diese Schlüsselworte nur den »Gegen- 
stand« (item) unmittelbar rechts davon ändern, ähnlich wie 
das Schlüsselwort const. Die Beschreibung des Handbuchs 
ist in diesem Punkt aber unvollständig. 

Wenn wir uns an die Diskussion der ANSI-Erweiterun- 
gen erinnern, bedeutet dies, daß die speziellen Schlüssel- 
worte entweder einen Bezeichner oder einen Zeiger 
ändern; das heißt, sie ändern Objekte oder Zeiger auf 
Objekte. Es besteht jedoch ein Unterschied darin, wie diese 
behandelt werden, der nicht klar aus dem Handbuch her- 
vorgeht. In Microsoft C ist die Syntax so, daß Zeiger von 
einem der speziellen Schlüsselworte geändert werden kön- 
nen. Daher ist eine Folge wie 


int (far * p); 


erlaubt, aber da ANSI eine solche Sytax verbietet, ist 


int (const * p); 


nicht erlaubt. 


Daraus ergibt sich, daß Microsoft C eine Deklarations- 
syntax wie 


MODIFIER * weitere_deklarations_inforsationen 


akzeptiert, wogegen ANSI nur 


* QUALIFIER weitere_deklarations_informationen 


akzeptiert, wobei MODIFIER und QUALIFIER optio- 
nale Positionsparameter sind. 

Bedenken Sie auch, daß far und near lange vor den 
ANSI-Erweiterungen const und volatile von Microsoft 
in die Sprache aufgenommen wurden. Der Grund für diesen 
unglücklichen Unterschied ist, daß ANSI die Syntax von 
Typenqualifizierern aus C+ + (einer Obermenge von C, die 
objektorientierte Programmierung erlaubt) übernommen 
hat, die unabhängig zur selben Zeit entwickelt wurde, wie 
Microsoft seine Modifizierer eingeführt hat. 

Das Gesagte über den Unterschied zwischen einem 
const-Zeiger und einen konstanten Zeiger gilt also auch 
hier. Bei diesen Attributen, zum Beispiel far, ist die Situa- 
tion sogar noch mehrdeutiger, da far bereits ein englisches 
Wort ist. Ist int *far p ein Far-Zeiger (weil p als Zeiger 
im far-Speicher angelegt wird), oder ist int far *pein 
far-Zeiger (da er auf eine far-Adresse zeigt)? 

Wir klären dies in genau derselben Weise, wie wir es mit 
const erledigt haben. Wir bleiben einheitlich und erklären, 
daß far * (ein Schlüsselwort ändert einen Zeiger) far- 
Zeiger bedeutet. Im anderen Fall sagen wir, daß der Zeiger, 
der im far-Speicher liegt, ein entfernter Zeiger ist. 

Ein letzter Punkt, der berücksichtigt werden muß, ist, 
daß die Speichermodell-Schlüsselworte von Microsoft C 
nicht mit automatischen Variablen verwendet werden kön- 
nen. Dies macht Sinn, da diese Variablen auf dem Stack 
geführt werden, und Sie keinen Einfluß darauf haben, ob 
der Stack near oder far ist. Dies bedeutet nicht, daß Sie 
keine lokalen statischen Variablen haben können, die near 
oder far sind; auch bedeutet es nicht, daß Sie keine auto- 
matischen Variablen verwenden können, die auf Daten in 
anderen Segmenten zeigen. Es bedeutet nur, daß eine auto- 
matische Variable selbst das Attribut nicht haben kann. 

Hier einige weitere Beispiele, die diese Punkte unter- 
streichen: 


int * far p; 


p ist ein entfernter Zeiger auf eine Integer. 


int far * p; 


p ist ein far-Zeiger auf einen Integerwert. Da ein far- 
Zeiger ein Zeiger auf far ist, ist p ein Zeiger auf eine far- 
Integer. 
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Die Entwicklung des Sprachenmarkts 


Der Sprachenmarkt hat sich seit 1975, als Microsoft das 
erste BASIC für den MITS ALTAIR herstellte, einschnei- 
dend verändert. Im folgenden werden die Entwicklungs- 
richtungen der Microsoft-Sprachenfamilie erörtert. Leitsatz 
dieser Bemühungen ist es, den Anwendern Werkzeuge zur 
Verfügung zu stellen, die ihren Bedürfnissen gerecht wer- 
den. 


Sprachen: Grundlage des Microsoft-Erfolgs 


Sprachen sind die Grundlage der Erfolgsgeschichte von 
Microsoft. Sie waren - mit dem ersten BASIC-Interpreter 
für den ersten im Handel erhältlichen PC - die Vorausset- 
zung für die Gründung der Firma. Sie sind heute die Werk- 
zeuge zur Entwicklung der Software, die Microsoft zum 
führenden PC-Softwareentwickler der Welt machte. 

Seit 1975, als Bill Gates den ersten BASIC-Interpreter 
für den MITS ALTAIR geschrieben hat, veränderte sich 
der Sprachenmarkt gewaltig. In den Anfängen des Micro- 
rechner-Zeitalters waren Programmierer eine auserwählte 
Minderheit, die die innere Logik des Geräts, das sie pro- 
grammierte, verstand und sich bequemte, Codezeilen zu 
schreiben, die nur wenige verstehen konnten. Heutzutage 
gibt es immer noch professionelle Programmierer, die auf 
dem Niveau der Assemblersprache arbeiten, aber die große 
Mehrheit befaßt sich mit höheren Programmiersprachen 
wie BASIC, C oder COBOL. Die wirklich spannenden 
Entwicklungen des Sprachenmarkts laufen allerdings nicht 
in diesem Bereich ab. Interessant wird es dort, wo sich eine 
riesige Anzahl von Ärzten, Rechtsanwälten, Börsen- und 
Immobilienmaklern und anderen Freiberuflern zum ersten 
Mal in die Heerscharen der Programmierer eingliedert. 

Warum sollten Leute ihre eigenen Anwendungen in 
einem Umfeld (IBM PC, PS/2 und kompatible Systeme) 
schreiben, das buchstäblich zehntausende von Anwendun- 
gen zur Verfügung stellt? Die Antwort liegt in den hervor- 
ragenden Werkzeugen, mit denen PC-Anwender heutzutage 
ihre EDV-Probleme lösen können. Im folgenden soll diese 
Entwicklung auf dem Sprachenmarkt und die Herausforde- 
rung, der sich Microsoft stellen muß, um die bestmöglichen 
Werkzeuge zur Deckung des Anwenderbedarfs zu schaffen, 
betrachtet werden. 


Die Marktentwicklung 


Seit den Anfängen der Microcomputerprogrammierung hat 
sich der Sprachenmarkt in zwei unterschiedliche Richtun- 
gen entwickelt - eine für professionelle Programmierer und 
die andere für Leute, die Software schreiben, um ihre 
Arbeit besser durchführen zu können oder um ihre Com- 
puterkenntnisse zu vertiefen. 


Die »Schnellprogrammierer« 


Die »Schnellprogrammierer« stellen das Marktsegment mit 
der höchsten Wachstumsrate und der rasantesten Entwick- 
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lung dar. Es handelt sich hierbei um nichtprofessionelle 
Programmierer, die eine Programmiersprache als Werk- 
zeug benutzen, um ihre Arbeit besser zu erledigen oder ihr 
Computersystem besser zu verstehen. Es überrascht nicht 
weiter, daß ihr Anforderungsprofil völlig verschieden von 
demjenigen der professionellen Programmierer ist. So 
unterschiedlich ihre Bedürfnisse sind, so unterschiedlich 
sind die Werkzeuge, die sie dafür benötigen. 

Diese Anwendergruppe ist schon wegen ihrer Größe 
interessant. Da sich BASIC bei einem der englischen Spra- 
che artverwandten Satzbau leicht erlernen läßt, entscheidet 
sich ein großer Teil dieser Menschen für Microsoft Quick- 
BASIC. Bei einer Analyse der Kundengruppe, die in letzter 
Zeit Microsoft QuickBASIC gekauft hat, wurden einige 
interessante Fakten ans Tageslicht gebracht. 

Zunächst einmal ergab sich, daß diese Menschen ein 
weit gefächertes Spektrum von Berufen ausüben, das vom 
Unternehmensberater über den EDV-Verwalter und Arzt 
bis zum Rechtsanwalt reicht. Gemeinsam ist ihnen die 
seriöse berufsmäßige Verwendung des PC als Arbeitswerk- 
zeug. Wie nachstehend ersichtlich ist, haben sie keine typi- 
schen Einsteigersysteme: 


CPU: 54% haben Systeme auf 80286- bzw. 
80386-Basis 

RAM: 96% verfügen über 640 Kbyte oder mehr 

Festplatte: 96% haben mindestens 10 Mbyte Fest- 
plattenspeicherplatz 

Maus: 61% verwenden eine Maus 


Ihre Motivation, das Programmieren zu lernen, läßt sich 
mit einfachen Worten beschreiben: Sie haben ein Problem 
und sie müssen es lösen. Für viele ist die erste Lösung der 
Kauf eines Anwendungspakets, zum Beispiel für Tabellen- 
kalkulation oder für die Datenbankverwaltung. Viele von 
ihnen sind jedoch mit der vom Anwendungspaket gebote- 
nen Lösung nicht zufrieden oder stellen fest, daß die Lei- 
stungsfähigkeit des Pakets zu beschränkt ist. Sie beschließen 
daher, ihre eigene Lösung zu entwickeln. 

Die von diesen Anwendern zu lösenden Probleme sind 
so vielfältig wie die Anwendungsmöglichkeiten des PC 
selbst: 


Kundenspezifische Listengenerierung T2% 
Kundenspezifische Datenbankverarbeitung 63% 
Grafik (außer Präsentationsgrafik) 53% 
aus Kalkulationstabellen und Datenbanken 52% 
Buchführungssysteme 45% 
Software-Entwicklungswerkzeuge 40% 
Kommunikation 39% 
Echtzeit-Prozeßsteuerung 37% 
Präsentationsgrafik 26% 
Computerspiele/Unterhaltung 25% 
Interrupt-Bearbeitung 20% 
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Durch diese Untersuchungsergebnisse bekam Microsoft 
eine Vorstellung von den Problemen, die diese Kunden- 
gruppe zu lösen versucht. Die nächste Frage, die gestellt 
werden mußte, war: »Wie entwickeln wir ein Produkt, das 
diesen Bedürfnissen gerecht wird?« Während des ganzen 
letzten Frühlings und Sommers ’88 wurden themenspezifi- 
sche Workshops veranstaltet und Durchführbarkeitsstudien 
erstellt, um die subjektiven Hindernisse besser zu verstehen, 
die die Interessenten davon abhielten, das Programmieren 
zu erlernen. Die bei weitem häufigste Antwort auf die Frage 
»Warum haben Sie bisher nicht versucht, selbst zu pro- 
grammieren?« lautete, man habe die Lernkurve anhand der 
heutigen Werkzeuge als zu lang und zu steil empfunden. 
Mit anderen Worten: der Einsatz, den diese Anwender 
benötigten, um produktiv zu sein, war zu hoch. 


Professionelle Programmierer 


Der heutige Berufsprogrammierer arbeitet in einem hart 
umkämpften Konkurrenzumfeld. Sowohl für diejenigen, die 
als gewerbliche Software-Anbieter arbeiten als auch für 
diejenigen, die als Firmenangestellte tätig sind, erfordert die 
Erstellung der schnellsten, kleinsten und sinnvollsten 
Anwendung Werkzeuge, die eine komplette Entwicklungs- 
lösung bieten. 

Die Anforderungen des berufsmäßigen Programmier- 
sprachen-Anwenders unterscheiden sich erheblich von 
denen des nicht berufsmäßigen Anwenders. Etwa 75% der 
C 5.0-Kunden sind berufsmäßige Programmierer, deren 
Haupteinnahmequelle das Schreiben von Software mit 
Microsoft C 5.0 ist. Sie schreiben mit C 5.0 unter anderem 
folgendes: 


Software-Entwicklungswerkzeuge 59% 
Kommunikation 56% 
Kundenspezifische Listengenerierung 55% 
Kundenspezifische Datenbankbearbeitung 55% 
Interrupt-Bearbeitung 54% 
Geräte-Treiber 40% 
Grafik (außer Präsentationsgrafik) 3% 


Statistische Analyse von Daten aus Kalkulationstabellen 


und Datenbanken 32% 
Integrierte Systeme (ROM-fähiger Code) 30% 
Buchführungssysteme 24% 
Echtzeit-Prozeßsteuerung 39% 
Präsentationsgrafik 20% 


Diese professionellen Programmierer setzen Eigen- 
schaften wie Leistungsfähigkeit, Betriebssicherheit und 
Herstellerrenomme&e an die Spitze ihrer Liste von Kaufkri- 
terien. Sie setzen auch auf die neueste Technologie: 41% 
von ihnen schreiben Anwendungen für Microsoft Windows 
und viele von ihnen haben mit der Entwicklung von Anwen- 
dungen für MS OS/2-Systeme begonnen bzw. planen diese. 


Die Herausforderung 


Ein Programmiersprachenanbieter muß sich der Heraus- 
forderung stellen, daß er das bestmögliche Werkzeug 
schaffen muß, um den Bedürfnissen dieser beiden Anwen- 
dergruppen gerecht zu werden. Microsoft ist der Meinung, 
daß es unmöglich ist, ein einziges Produkt herzustellen, das 
den Bedürfnissen sowohl der berufsmäßigen Anwender als 
auch der Einsteiger gerecht wird. Dazu sind ihre Bedürf- 
nisse, ihre Erwartungen und vor allen Dingen die Art, wie 
sie die Produkte anwenden, zu unterschiedlich. Daher hat 
Microsoft zwei sehr verschiedene Produktfamilien ent- 
wickelt, um den Bedarf dieser zwei Segmente zu decken. In 
beiden Fällen geht es primär darum, dem Kunden das 
bestmögliche Werkzeug zu bieten. 

So ist zum Beispiel Benutzerfreundlichkeit für beide 
Segmente wichtig, wobei eine einfache, feste EDV-Umge- 
bung mit unkompliziertem Editor und Testsystem für 
Anfänger durchaus ausreichen kann, aber eine weitaus dif- 
ferenziertere und flexiblere Programmumgebung für Pro- 
grammentwickler benötigt wird, die eine Vielzahl von 
Werkzeugen, hoch konfigurierten (individualisierten) Edito- 
ren und leistungsstarken Testsystemen verwenden, um rie- 
sige Anwendungen zu schreiben, die auf verschiedenen 
Ebenen laufen (MS-DOS, Microsoft Windows, MS OS/2). 
Diese Unterschiede erfordern einen differenzierten Aufbau 
der Werkzeuge, bei dem eine klare Gewichtung der Ver- 
hältnisse zwischen Merkmalen wie Kompiliergeschwindig- 
keit und Codeausführungsgeschwindigkeit oder verwende- 
tem Speicherplatz und Funktionalität erfolgt. 

Der Microsoft-Leitgedanke bei den Quick-Sprachen ist 
es, den Anwender so schnell wie möglich über die Lern- 
kurve zu führen. Dieser Vorgang wird als »Beherrschungs- 
freundlichkeit« bezeichnet. Microsoft QuickBASIC 4.0 ist 
das gegenwärtige Vorzeigeprodukt für diese Strategie - 
Nachfolgeprodukte sind in der Entwicklung. Bei Microsoft 
QuickBASIC 4.0 verknüpften sich die Bedienungsfreund- 
lichkeit und die Dialogfähigkeit eines Interpreters mit der 
modernsten, am weitesten strukturierten BASIC-Version 
aller Zeiten. 

Im Gegensatz zu den Lernwerkzeugen für den Ein- 
stiegsprogrammierer, entwickeln sich die professionellen 
Werkzeuge von Microsoft dem neuesten Stand der Technik 
entsprechend weiter und bieten damit eine komplette Ent- 
wicklungslösung für den Programmierer, dessen Einkom- 
men von den Werkzeugen, die er verwendet, abhängt. Diese 
Entwicklung wird sich schwerpunktmäßig auf drei Bereiche 
konzentrieren. 


Die Entwicklung von Schlüsseltechnologien 


Microsoft ist ein Unternehmen, das auf der Grundlage von 
Technologie aufgebaut wurde. Ob bei Betriebssystemen, 
Programmiersprachen oder Anwendungen, die grund- 
legende Produkttechnologie muß den neuesten Stand der 
Technik darstellen. Bei Programmiersprachen betrifft dies 
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Produkte wie Codegeneratoren, Testsysteme und sonstige 
Werkzeuge, EDV-Umgebungen, die die Entwicklung von 
Software durch Arbeitsgruppen unterstützen sowie objekt- 
orientiertes und visuelles Programmieren für grafische 
Anwenderinterfaces wie Microsoft Windows und den Pre- 
sentation Manager. 


Zunehmende Produktivität der Programmierer 


Berufsmäßige Programmierer mußten sich bisher mit 
dezentralen Werkzeugen zufriedengeben, die wenig oder 
gar keine Integration zuließen. Eine wirklich fortschritt- 
liche, integrierte Entwicklungsumgebung muß _ flexibel 
genug sein, um das breite Spektrum an Werkzeugen, das die 
Profis installieren möchten, zu handhaben, und leistungs- 
stark genug sein, um die riesigen Anwendungen, die ent- 
wickelt werden, zu bearbeiten. 


Rechtzeitige Unterstützung von 
neuen Betriebssystemen und neuer Hardware 


Professionelle Programmentwickler verlangen Werkzeuge 
von einer Leistungsfähigkeit, die die Ausnutzung neuer 
Hardware und neuer System-Softwareebenen ermöglicht. 
Mit dieser Unterstützung kann der Profi rasch in den heiß 
umkämpften Software-Entwicklungsmarkt eindringen. 


Unsere Antwort auf die Herausforderung 


Microsoft entwirft jede Quick-Sprache und jede professio- 
nelle Sprache mit einem Ziel: Das beste Werkzeug für den 
jeweiligen Anwenderkunden zu entwickeln. Bei den profes- 
sionellen Sprachen bedeutet dies die Erstellung einer kom- 
pletten Entwicklungslösung, das heißt von Werkzeugen, die 
die Leistungskraft bieten, welche der berufsmäßige Pro- 
grammentwickler benötigt. Bei den Quick-Sprachen bedeu- 
tet es, neue Maßstäbe in der »Beherrschungsfreundlich- 
keit«, dem Abkürzen der Lernkurve und dem raschen 
Ermöglichen von Anwenderproduktivität zu setzen. 


Entwickler des VMS-Betriebssystems kommt zur 
Microsoft-»Operating Systems Group« 


Der Entwickler einiger der erfolgreichsten Betriebssysteme 
der Digital Equipment Corporation, David Cutler, ist zur 
Microsoft Corporation gewechselt, um dort ein Entwick- 
lungs-Team für fortschrittliche Betriebssystem-Software zu 
leiten. 

Cutler, der 17 Jahre lang bei Digital Equipment tätig 
war, hat an der Entwicklung und Implementierung des 
RSX-11M-Betriebssystems für die PDP-11-Computer - das 
Digital Equipment in den 70er Jahren zum führenden 
Unternehmen bei Echtzeit-Systemen gemacht hat - und an 
der Entwicklung des VMS-Betriebssystems für die VAX- 
Computer - mit dem Digital in den 80er Jahren zum 
Marktführer bei Minicomputern wurde - wesentlich mitge- 
wirkt. 
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Zusätzlich zu seiner Tätigkeit bei der Entwicklung von 
Betriebssystemen war Cutler auch an der Entwicklung von 
Computer-Architekturen und Hardware beteiligt. Sein 
Team erstellte bei DECwest in Seattle den MicroVAX- 
Computer, Digitals erste Implementierung der VAX-Archi- 
tektur auf einem Mikrocomputer. Cutler hat außerdem um- 
fangreiche Erfahrungen in der Compiler-Entwicklung durch 
die Implementierung von PL/1-, C- und anderen Sprachen- 
Compilern. 

David Cutler war einer von drei »Senior Corporate Con- 
sultant« in der gesamten Digital Equipment Corporation. 
Bei Microsoft leitet er ein Team, das sich auf die Entwick- 
lung zukünftiger Versionen von Microsoft-OS/2 und ande- 
rer fortschrittlicher Betriebssystem-Software konzentriert. 

Steve Ballmer, Vice President of Systems Software bei 
Microsoft, sagte anläßlich des Wechsels von David Cutler, 
daß Microsoft außerordentlich erfreut darüber ist, einen 
Mann mit den Fähigkeiten und Erfahrungen David Cutlers 
nun in den eigenen Reihen zu haben. Die Einstellung David 
Cutlers durch Microsoft zeige außerdem deutlich das Enga- 
gement für MS OS/2 als Software-Plattform der Zukunft. 
»David ist als jemand anerkannt, der große Projekte leiten 
und sie pünktlich und in höchster Qualität ausführen kann«, 
fügte Ballmer hinzu. 

David Cutler sagte zu seinem Start bei Microsoft, daß er 
darin eine einzigartige Möglichkeit sieht, seine berufliche 
Karriere in einen Bereich der Computertechnik auszudeh- 
nen, in dem er bisher noch nicht gearbeitet hat. Er sieht 
sich selbst mehr als Leiter eines Teams denn als Manager 
und ist der Meinung, daß eine gute Leitung ausschlag- 
gebend für erfolgreiche Entwicklungsteams ist. 


MS OS/2 jetzt mit 
Presentation Manager 


Microsoft und IBM kündigten vor kurzem, wie verspro- 
chen, die Auslieferung der gemeinsam entwickelten Version 
1.1 des Betriebssystems OS/2 mit dem Presentation Mana- 
ger an. Der Presentation Manager, die grafische Bedie- 
nungsoberfläche für das OS/2-Betriebssystem, wurde mit 
der OS/2-Version 1.0 im April 1987 angekündigt. IBM 
begann mit der Auslieferung der Version 1.0 von OS/2 im 
Dezember 1987. Die jetzige Vorstellung ist das zweite 
große Release der Standardversion von OS/2. IBM kün- 
digte die sofortige Auslieferung der OS/2-Version 1.1 an. 
Microsoft wird mit seinen anderen OEM-Kunden daran 
arbeiten, MS OS/2 in der Version 1.1 für die Computer- 
Hardware dieser Hersteller auszulegen. Es wird erwartet, 
daß die anderen Computer-Hersteller mit der Auslieferung 
von OS/2, Version 1.1, Anfang 1989 beginnen. 

Im Rahmen einer Presseveranstaltung in New York 
zeigten IBM, Microsoft und eine Reihe anderer Software- 
Hersteller neuentwickelte Produkte für den Presentation 
Manager. Folgende Unternehmen demonstrierten neue 
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Produkte oder kündigten die Unterstützung von OS/2, Ver- 
sion 1.1, an: Aldus, Ashton Tate, Borland, Computer Asso- 
ciates, Digital Research, IBM, Lotus, mdbs, Micrographx, 
Microrim, Software Publishing, 3Com, Versacad, Word- 
Perfect und Xcellenct. Microsoft selbst zeigte in New York 
MS-Excel für den Presentation Manager. 

OS/2 ist nicht nur die Betriebssystem-Plattform für eine 
ganz neue Generation von Anwendungs-Software, es ist in 
gleichem Maße die Basis für wichtige Neuentwicklungen bei 
lokalen Netzwerken, Kommunikations- und Datenbank- 
Produkten, wie zum Beispiel IBM-Extended Edition, 
Microsoft-LAN-Manager, Ashton-Tate/Microsoft-SOL- 
Server sowie weiterer ähnlicher Produkte. 

MS OS/2 wird nach Meinung von Christian Wedell, 
Geschäftsführer der deutschen Microsoft GmbH, einen 
außerordentlich starken Einfluß auf den PC-Markt haben, 
weil in einem vergleichbaren Zeitraum sehr viel mehr 
Computer-Hersteller OS/2 anbieten und viel mehr Anwen- 
dungen verfügbar sein werden, als für MS-DOS. Ein großer 
Anteil dieser Aktivitäten richtet sich auf die Entwicklung 
von Anwendungs-Software für den MS OS/2-Presentation 
Manager. Microsoft sieht deshalb die planmäßige Ausliefe- 
rung der OS/2-Version 1.1 als einen wichtigen Meilenstein 
auf dem Wege, neue Anwendungs-Software auf den End- 
anwender-Markt zu bringen. 

OS/2 mit Presentation Manager bietet eine volle Unter- 
stützung für den Protected-Mode-Betrieb von PCs auf 
80286- und 80386-Prozessor-Basis. Den Anwendern stehen 
nun 16 Mbyte physischer Hauptspeicher und 1 Gbyte virtu- 
eller Speicher über ein Standardgrafik-Bedienungsinterface 
zur Verfügung, das die OS/2-Schlüsselfunktionen, wie zum 
Beispiel Multitasking, einfach bedienbar machen. 

Ein wichtiges Merkmal für Software-Entwickler ist das 
hochentwickelte, prioritätsgesteuerte, wahlfreie Steuerpro- 
gramm (Preemptive Scheduler), das durch einen umfang- 
reichen Satz von Interprozeß-Kommunikationsmöglichkei- 
ten unterstützt wird. Anwendungen lassen sich als eng 
zusammenarbeitende Gruppen von Tasks entwickeln, 
woraus sich eine verbesserte Effizienz und die Basis für 
echte Netzwerk-Anwendungen ergibt. 


MS-Excel erstes Anwendungsprogramm 
für den Presentation Manager 


Microsoft zeigte in diesen Tagen mit Excel für den Pre- 
sentation Manager die erste Anwendungs-Software, die die 
Version 1.1 des Betriebssystems MS OS/2 unterstützt. 
Microsoft Excel ist das erste Tabellenmanagement-Pro- 
gramm, bei dem die Vorteile der grafischen Bedienungs- 
umgebung genutzt werden, um hohe Funktionalität, zahlrei- 
che Darstellungsmöglichkeiten und gute individuelle 
Anpaßbarkeit zu bieten. Microsoft Excel ist nicht nur das 
führende Tabellenkalkulations-Programm auf dem Apple- 
Macintosh, es gewinnt auch in der Windows-Version mit 


mehr als 20.000 im Monat weltweit verkauften Paketen 
einen schnell wachsenden Anteil im MS-DOS-Markt. 

Obwohl Microsoft noch keinen genauen Termin und 
Preis für die MS OS/2-Version von Microsoft Excel 
genannt hat, wurde bestätigt, daß bisherige Besitzer von 
Microsoft Excel für Windows zu einem günstigen Upgrade- 
Preis auf Microsoft Excel für den Presentation Manager 
umsteigen können. 

Die Entwicklung der MS OS/2-Version von Microsoft 
Excel ist derzeit schon weiter gediehen als geplant war. 
Microsoft entwickelt schon seit mehreren Jahren Anwen- 
dungsprogramme für Microsoft Windows und für den Mac- 
intosh und hat mit grafischen Bedienungsumgebungen mehr 
Erfahrung als andere Hersteller von Anwendungs-Software. 
Die Entwicklung von Microsoft Excel für MS OS/2 geht 
reibungslos voran, so daß zu erwarten ist, daß Microsoft 
Excel das erste Tabellenkalkulations-Programm sein wird, 
das für den Presentation Manager verfügbar ist. 

Zusätzlich zur Familie der Microsoft Windows-Produkte 
plant Microsoft eine komplette Linie von Anwendungspro- 
grammen für den Presentation Manager. Da bei den 
Anwendungsprogrammen mit einer einheitlichen »Core 
Engine of Code« gearbeitet wird, müssen Microsoft Win- 
dows-Anwendungen nicht vollständig für MS OS/2-1.1 
umgeschrieben werden. Etwa 80 Prozent des Programm- 
codes lassen sich auch unter MS OS/2 einsetzen. Alle 
geplanten Anwendungsprogramme von Microsoft werden 
mit einem gemeinsamen Bedienungs-Interface ausgestattet 
sein, so daß die Trainings- und Supportkosten reduziert 
werden und die Anwender auf einfachere Weise mit mehre- 
ren Anwendungen arbeiten können. 


Excel für den Presentation Manager 
zeigt die Vorzüge von MS OS/2 


Microsoft Excel für den Presentation Manager wird mit 
Microsoft Excel 2.1, der derzeitigen Windows-Version, 
vieles gemein haben. Beide Versionen entsprechen dem 
IBM-CUA-Standard (Common User Access) und haben 
das gleiche Interface. Anwender, die auf die neue Version 
umsteigen wollen, müssen deshalb kein neues Programm 
lernen. Beide Versionen haben darüber hinaus auch identi- 
sche Dateiformate, so daß keine Daten geändert werden 
müssen. Neben der Verringerung der Trainingskosten wird 
Microsoft Excel für den Presentation Manager auch die 
anderen Nutzeffekte bieten, die mit MS OS/2 verbunden 
sind. 

MS OS/2 ermöglicht es, daß Microsoft Excel vollständig 
in den Arbeitsspeicher geladen werden kann. Ein Hin- und 
Herladen zwischen Arbeitsspeicher und Massenspeicher ist 
deshalb nicht nötig. Zahlreiche Tasks werden sehr viel 
schneller laufen, zum Beispiel das Drucken, die grafische 
Darstellung, Makros und der Bildschirmaufbau. Die 
Anwender werden außerdem in der Lage sein, sehr viel 
größere Tabellen zu erstellen, ohne Speichererweiterungs- 
Platinen oder Treiber zu benötigen. Der Presentation 


Januar/Februar 1989 Microsoft System Journal 5 1 


Mitteilungen 


Mitteilungen .... Mitteilungen .... Mitteilungen 


Manager macht es möglich, daß zwischen Microsoft Excel 
und anderen MS OS/2-Anwendungen einfach hin- und her- 
geschaltet werden kann. MS OS/2 erlaubt echten Multitask- 
ing-Betrieb, so daß Microsoft Excel zum Beispiel im 
Hintergrund arbeiten kann, während der Anwender auf 
dem Bildschirm eine andere Anwendung laufen läßt. Die 
Presentation Manager-Version von Microsoft Excel wird 
nicht zuletzt auch bei Netzwerk-Betrieb eine wesentlich 
höhere Leistung bieten, weil sowohl der Netzwerk-Treiber 
als auch Microsoft Excel komplett in den Hauptspeicher 
ladbar sind, so daß beim Betrieb nicht immer wieder auf die 
Festplatte zugegriffen werden muß. Die Anwender von 
Microsoft Excel für den Presentation Manager werden 
außerdem feststellen, daß die Erstinstallation einfacher ist, 
weil Speichertreiber und Festplatten-Zugriffs-Utility nun 
nicht mehr notwendig sind. 


Microsofts Pläne zur Drucker-Unterstützung für 
den Presentation Manager 


Unlängst gab Microsoft bekannt, daß eine umfassende 
Unterstützung für eine breite Palette von Druckertreibern 
unter MS OS/2-Presentation Manager geplant ist. Die 
Treiber-Software wird zusammen mit der Firma Bauer 
Enterprises, San Jose, Kalifornien, entwickelt und soll 
Bestandteil der Standardversion MS OS/2-1.1 sein. Sie wird 
darüber hinaus allen MS OS/2-OEM-Lizenznehmern zur 
Verfügung stehen. 

Die Druckertreiber-Software mit der Bezeichnung 
»Generic Printer Driver« unterstützt eine breite Palette von 
Geräten, wie Matrix-, Typenrad- und Laserdrucker. Die 
Unterstützung für Laserdrucker schließt auch Drucker mit 
HP-PCL-Emulation ein. Die »Generic Printer Driver«- 
Software vereinfacht insbesondere den Aufwand, den die 
Druckerhersteller üblicherweise treiben müssen, um eine 
entsprechende Unterstützung ihrer Produkte durch das 
Betriebssystem zu gewährleisten. Im wesentlichen ent- 
wickelt der Druckerhersteller nun nur noch eine einzige 
Tabelle, als Drucker-Beschreibungstabelle bezeichnet, die 
die Merkmale und Funktionen des Geräts spezifiziert. Die 
Informationen dieser Tabelle werden dann durch den 
»Generic Driver« geladen und zur Ansteuerung des jeweili- 
gen Druckers benutzt. Dieses Verfahren entbindet den 
Druckerhersteller von der erheblich komplexeren Aufgabe, 
einen speziellen MS OS/2-Treiber für einen bestimmten 
Drucker zu entwickeln. 

Die Firma Bauer Enterprises wird den Druckerherstel- 
lern ein Entwicklungs-Kit zur Verfügung stellen, das die 
Entwicklung und den Test von Drucker-Beschreibungs- 
tabellen ermöglicht. Darüber hinaus bietet Bauer Enterpri- 
ses einen Prüf- und Wartungsservice an, der die Fehlerfrei- 
heit der Drucker-Beschreibungstabellen und eine rechtzei- 
tige Erweiterung für neue Druckermodelle sicherstellen 
soll. Die Generic-Druckertreiber-Software wird für 
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Microsoft-OS/2-OEM-Kunden im ersten Quartal 1989 
verfügbar sein. 

»Microsoft entschied sich auf diesem diffizilen Feld für 
eine Zusammenarbeit mit Bauer Enterprises, weil dieses 
Unternehmen eine reiche Erfahrung in der Entwicklung 
von Drucker-Software hat«, so Christian Wedell, Geschäfts- 
führer der deutschen Microsoft GmbH, zu der Kooperation 
mit Bauer Enterprises. 

Bei Bauer Enterprises geht Cal Bauer, Gründer und 
Präsident des Unternehmens, davon aus, daß die Zusam- 
menarbeit mit Microsoft eine hervorragende Nutzung des 
Know-hows ermöglicht, das sein Unternehmen in puncto 
Druckertreiber-Software besitzt. Bauer ist außerdem der 
Meinung, daß MS OS/2 ein führendes Betriebssystem im 
Bürocomputer-Bereich wird und daß die Generic-Drucker- 
treiber-Software eine ausgezeichnete Lösung für eine große 
Zahl von Druckerherstellern ist. 

Zahlreiche führende Druckerhersteller planen die 
Unterstützung ihrer Drucker in Bezug auf den MS OS/2- 
Presentation Manager und stehen zur Zeit in der Diskus- 
sion über die Generic-Druckertreiber-Software mit Micro- 
soft und Bauer. Diese Druckerhersteller repräsentieren 
mehr als 80 Prozent des weltweiten PC-Druckermarkts und 
schließen Firmen wie Alps America, Brother International, 
Citizen, Dataproducts Corporation, Fujitsu, Epson, NEC 
Information Systems, Office Automation Systems Inc., 
Okidata, Olivetti, Ricoh, TEC und Toshiba ein. 

Steve Lapinski, Vize-Präsident für Marketing bei Epson, 
äußerte, daß der MS OS/2-Presentation Manager eine 
wirklich neue Betriebssystem-Umgebung für den heutigen 
Anwender darstellt und daß Epson plant, den Presentation 
Manager für seine umfassende Druckerpalette voll zu 
unterstützen. 

Antonio Maccari, Manager für Forschung und Ent- 
wicklung bei Olivetti, sagte, daß Olivetti kürzlich die Bauer- 
Technologie für seine PostScript-kompatiblen Drucker 
übernommen hat und man im Hause Olivetti der Meinung 
ist, daß die Kooperation zwischen Microsoft und Bauer 
Enterprises ein wichtiger Faktor für die Etablierung eines 
Standard-Druckerinterfaces innerhalb von MS OS/2-Pre- 
sentation Manager ist. Olivetti lege sich auf den neuen 
Standard fest, fügte Maccari hinzu. 

Bruce Friesen, Direktor für das Drucker-Marketing der 
Information Systems Division von Toshiba Amerika, führte 
aus, daß Toshiba Amerika die MS OS/2-Presentation 
Manager-Druckersupport-Strategie voll  unterschreibt. 
Toshiba Amerika erwarte von der Generic-Druckertreiber- 
Software erhebliche Einsparungen an Zeit und Ressourcen. 
»Es ist gut zu wissen, daß die Toshiba-Drucker alle Anwen- 
dungen komplett unterstützen werden, wenn der MS OS/2- 
Presentation Manager auf den Markt kommt«, setzte 
Friesen hinzu. 

Alex Schibanoff, Marketing Direktor der Brother Inter- 
national, vertrat die Ansicht, daß die Entwicklung eines 
Industrie-Standard-Druckertreibers für den MS OS/2-Pre- 
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sentation Manager ein Beispiel dafür ist, daß Microsoft die 
führende Position im Bereich der PC-Software erreicht hat. 
Schibanoff ist außerdem der Meinung, daß sowohl PC- 
Anwender, Software-Entwickler und Druckerhersteller 
einen Nutzen durch die neue Treiber-Software haben. 

Die Bauer Enterprises wird neben dem Generic-Treiber 
für den MS OS/2-Presentation Manager einen äquivalenten 
Treiber für Microsoft-Windows entwickeln. Das Format der 
Drucker-Beschreibungstabellen für MS-Windows wird 
identisch zu dem für den MS OS/2-Presentation Manager 
sein. Dies bedeutet gleichzeitig eine weitere Reduzierung 
des Aufwands, den die Druckerhersteller bei der Entwick- 
lung von Treiber-Software für ihre Produkte treiben müs- 
sen. Microsoft hat die Absicht, den Generic-Treiber in 
zukünftige Versionen von MS-Windows zu integrieren. 

Für die Hewlett-Packard Company, die Hersteller einer 
Reihe weitverbreiteter PC-Drucker einschließlich des HP- 
LaserJets-I ist, kommentierte William P. McGlynn, Marke- 
ting Manager der HP Boise Printer Division, die Entwick- 
lung der Generic-Treiber-Software mit den Worten: »Hew- 
lett-Packard sieht den MS OS/2-Presentation Manager als 
den kommenden Standard! Wir arbeiten eng mit Microsoft 
zusammen, um den Anwendern dieser Betriebssystem-Um- 
gebung hochqualitative Druckerlösungen von Hevwlett- 
Packard bieten zu können.« 


Hintergrund-Informationen zu Geräte-Treibern 


Geräte-Treiber sind Software-Komponenten, die der 
Kommunikation zwischen dem Betriebssystem und Hard- 
ware-Einheiten, wie Disketten-/Festplatten-Laufwerken, 
Bildschirmen und Druckern dienen. Sie bilden eine Trenn- 
stelle zwischen dem Betriebssystem sowie der Anwendungs- 
Software auf der einen Seite und den Hardware-Einheiten 
auf der anderen Seite. Unter dem MS OS/2-Presentation 
Manager arbeitet die Anwendungs-Software in einer gerä- 
teunabhängigen Weise, die es möglich macht, daß zum Bei- 
spiel ein Dokument ohne weiteres auf verschiedenen 
Druckern ausgegeben werden kann. Die Anwendungs-Soft- 
ware benötigt dafür keine Informationen über die physi- 
schen Merkmale der jeweiligen Drucker. 

Bauer Enterprises hat seit seiner Gründung im Jahre 
1985 Treiber-Software für Microsoft entwickelt und ge- 
testet. Das Unternehmen ist führend in der Drucker-Soft- 
ware-Technik und bietet Druckerherstellern eine komplette 
Palette von Software-Werkzeugen und Dienstleistungen an. 
Bauer beschäftigt sich mit Anwendungs-Software, Kompa- 
tibilitätstests, Anwendungstreiber-Entwicklung und der 
Entwicklung von Druckersprachen. Die Firma hat Betriebs- 
stätten in San Jose, Kalifornien, sowie in Taipeh, Taiwan, 
und beschäftigt 40 Mitarbeiter, von denen 27 Software-Inge- 
nieure sind. 


Microsoft und Hewlett-Packard portieren 
den MS OS/2-Presentation Manager auf Unix 


Microsoft, Santa Cruz Operation (SCO) und Hewlett- 

Packard haben kürzlich eine Vereinbarung zur gemein- 

samen Entwicklung einer Unix-Version des MS OS/2-Pre- 

sentation Managers bekanntgegeben. Doug Michels, Mitbe- 
gründer und Vize-Präsident von SCO, erklärte anläßlich 
dieser Ankündigung vor der Presse: »Der Presentation 

Manager/X ist kompatibel mit X Window-Anwendungen 

und erlaubt es Anwendern, sowohl X- als auch Presentation 

Manager-Anwendungen mit dem selben Interface zu nut- 

zen. Damit kommen sich MS-DOS bzw. MS OS/2 und 

SCO-Unix aus Anwendersicht ein gutes Stück näher - eine 

Entwicklung, die Microsoft und Santa Cruz Operation seit 

Jahren betreiben.« 

Der Presentation Manager/X stellt eine Erweiterung 
des Common X Interface (CXT) dar, das ebenfalls in diesen 
Tagen angekündigt wurde, und ist der nächste Schritt in 
Richtung Anwendungsportabilität bei verschiedenen Be- 
triebssystemen. Das grafische Bedienungsinterface CXI 
verleiht der Unix-Bedienungsoberfläche dasselbe Aussehen 
und die Funktionen, wie sie von PCs bekannt sind, die unter 
MS-DOS mit Microsoft Windows oder MS OS/2 mit dem 
Presentation Manager laufen. Außerdem hat der Presenta- 
tion Manager/X Anwendungsprogramm-Interfaces (API), 
die denjenigen des MS OS/2-Presentation Manager ent- 
sprechen. Der Presentation Manager/X bietet zwei wesent- 
liche Vorzüge: 

1. In Verbindung mit CXI ermöglicht er es Anwendern, 
die mit Microsoft Windows oder mit MS OS/2-Presen- 
tation Manager vertraut sind, auch auf entsprechenden 
Unix-Computern ohne großen Lernaufwand zu arbeiten. 

2. Der Anwender kann auf einfache Weise Anwendungen 
von MS OS/2 1.1 auf Unix und umgekehrt transportie- 
ren. 

»Unix-Software-Entwickler wollen eine stabile grafische 
Betriebssystem-Umgebung haben, die drei Merkmale auf- 
weist: eine gute Bedienungs-Interface-Technik, die Unter- 
stützung durch einen führenden Hersteller sowie eine rei- 
bungslose Portiermöglichkeit zwischen OS/2 und Unix. Der 
Presentation Manager/X hat alle drei Merkmale«, so 
Christian Wedell, Geschäftsführer der Microsoft GmbH. 

Microsoft, Santa Cruz Operation und Hewlett-Packard 
entwickeln den Presentation Manager/X als Reaktion auf 
Marktanforderungen. Da der Presentation Manager/X 
sowohl auf Intel- als auch auf Nicht-Intel-Hardware einge- 
setzt werden kann, ergibt sich für die Entwickler von 
Anwendungs-Software ein großer Zielmarkt. 

Hewlett-Packard ist der erste führende Computer-Her- 
steller, der bekanntgab, daß er den Presentation Mana- 
ger/X einsetzen wird. Er wurde außerdem der Open-Soft- 
ware-Foundation (OSF) als Reaktion auf die kürzliche Aus- 
schreibung der OSF für zukünftige Erweiterungen des 
Common X Interfaces unterbreitet. 


Januar/Februar 1989 Microsoft System Journal 53 


Mitteilungen 


Mitteilungen .... Mitteilungen .... Mitteilungen 


Der Presentation Manager/X ist so ausgelegt, daß er 
mit dem Industrie-Standard X-Window-System koexistieren 
kann. Da das X-Window-System die Basis für CXI ist, wer- 
den CXI- und Presentation Manager/X-Anwendungen 
gleichzeitig auf dem Bildschirm laufen können. 

Die Verfügbarkeit und der Preis für den Presentation 
Manager/X-Toolkit werden in der ersten Hälfte dieses Jah- 
res bekanntgegeben. 


Microsoft liefert MS-DOS 4.01 OEM-Paket aus 


Microsoft gab kurz vor Jahreswechsel bekannt, daß die 
Auslieferung des Software-Pakets MS-DOS 4.01 zusammen 
mit der MS-DOS-Shell an die Hersteller von Personalcom- 
putern begonnen hat. Diese Version, mit dem Namen MS- 
DOS Betriebssystem Version 4.01, ist vollständig kompatibel 
mit PC-DOS 4.01 und beinhaltet eine verbesserte Unter- 
stützung der »Expanded Memory Specification« (EMS). 
PC-DOS 4.01 ist die aktuelle DOS-Version, welche die IBM 
derzeit zusammen mit ihren PCs ausliefert. 

Das MS-DOS 4.01 System bietet eine DOS-Bedienungs- 
oberfläche, die es als grafisches Datei-Management-System 
dem Anwender erlaubt, über die grafische Eingabe Fest- 
platten-Dateien zu handhaben, Anwendungen zu starten 
und die Basis-DOS-Funktionen per Pull-Down-Menü und 
Dialog-Fenster auszuwählen. Bisherige MS-DOS Versionen 
hatten ein zeichen-/zeilenorientiertes Interface (Prompt 
Command Line), bei dem der Anwender die Befehle als 
definierte Zeichenketten eingeben mußte. 

»Die DOS-Shell bietet MS-DOS Anwendern die Vor- 
teile einer grafischen Bedienungsoberfläche, wobei der 
Anwender nun mit dem MS-DOS-4.01-Interface auf ver- 
gleichbare Weise arbeiten kann wie auf höherer Ebene mit 
dem MS OS/2 Presentation Manager, so Christian Wedell, 
Geschäftsführer der deutschen Microsoft GmbH, zur Aus- 
lieferung von MS-DOS 4.01. 

Die Reaktion der Anwender auf die neue grafische 
DOS-Oberfläche ist nach Meinung von Jerry Schneider, 
ehemaliger Präsident und Gründungsmitglied der Capital 
PC User Group Inc., positiv, weil die DOS-Shell die Lei- 
stung und Vielseitigkeit des Betriebssystems für den 
Anwender erschließt, ohne daß er ein umfangreiches Wis- 
sen über Befehle und deren Syntax haben muß. Auch 
Anfängern ermöglicht die neue DOS-Shell durch die ein- 
fache Bedienbarkeit schnell die ganze Leistungsfähigkeit 
des Betriebssystems zu nutzen. 

Ein weiteres Merkmal der MS-DOS Version 4.01 ist der 
LIMulator, ein Treiber, der in PCs auf 80386-Basis die Nut- 
zung eines erweiterten Hauptspeichers ermöglicht. Darüber 
hinaus bietet die MEM-Utility in MS-DOS 4.01 dem 
Anwender die konventionelle Adressierung des Hauptspei- 
chers. Die neue Betriebssystemversion unterstützt Fest- 
plattenpartitionen mit einer Größe von mehr als 32 Mbyte. 
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Das mit Microsoft-Label versehene Software-Paket aus 
MS-DOS 4.01 und MS-DOS-Shell wird direkt an die Hard- 
ware-Kunden geliefert. Wie auch schon bei früheren Ver- 
sionen, handelt es sich bei MS-DOS 4.01 um ein reines 
OEM-Lizenzprodukt, das von Microsoft nicht direkt an 
Endkunden bzw. Händler ausgeliefert wird. Microsoft geht 
davon aus, daß OEM-Lizenznehmer im ersten Quartal 1989 
damit beginnen, modifizierte MS-DOS 4.01 Versionen aus- 
zuliefern. Der Vertrieb der MS-DOS 4.01 US-Version 
erfolgt ausschließlich über Hardware-Hersteller. 


Textverarbeitung auf dem Macintosh 
mit Word 4.0 optimiert 


Microsoft stellte in diesen Tagen die neue Version des 
Textverarbeitungs-Programms Microsoft Word 4.0 für den 
Macintosh vor, das den Anwendern große Leistungsfähig- 
keit und Flexibilität im gesamten Bereich der professionel- 
len Textverarbeitung ermöglicht. Das Programm bietet eine 
Vielzahl individueller Spezifikationen, einfache Hand- 
habung und Kompatibilität zu anderen Software-Produkten. 
»Die umfangreiche Erweiterung der neuen Version 
macht deutlich, daß Microsoft auf die Wünsche der Macin- 
tosh-Anwender eingegangen ist und die Gelegenheit wahr- 
genommen hat, zahlreiche Funktionen in das Programm 
aufzunehmen, die von den Anwendern gewünscht wurden«, 
erläutert Microsoft-Geschäftsführer Christian Wedell. 
Microsoft Word 4.0 ist mit speziellen Funktionen ausge- 
stattet, die die Vorzüge des Macintosh verstärkt nutzbar 
machen. Das Programm läuft auf allen Macintosh-Compu- 
tern mit einer Hauptspeicher-Kapazität von mindestens 512 
Kbyte. Die neuen Funktionen umfassen: 
u PageView, eine WYSIWYG-Editierumgebung, 
» Tabellen zur einfachen Positionierung von spaltenbezo- 
genen Absätzen, Zahlen oder Grafiken, 
s eine automatische Umpaginierung, 
» die Möglichkeit, Text um Objekte herumfließen zu 
lassen, 
ı Farb-Unterstützung sowie 
® cine automatische Dateien-Verknüpfung mit Microsoft 
Excel und Microsoft Mail. 
Jedes Microsoft Word-4.0-Paket beinhaltet das Word 
Finder-Wörterbuch und das AutoMac-Makroprogamm. 


Neue Funktionen bieten neue Möglichkeiten 


Microsoft Word 4.0 bietet nun vier verschiedene Editier- 

Betriebsarten: 

" cinen verbesserten »Outlining«-Modus zur Strukturie- 
rung des Dokumenteninhalts, 

u einen »Galley«-Modus zum schnellen Editieren langer 
Dokumente, 

s einen »Page«-Modus für die seitenorientierte WYSI- 
WYG-Editierung sowie 

" einen »Print-Preview«-Modus zur Seitengestaltung. 
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Mit Microsoft Word 4.0 können Anwender Befehle zu 
jedem Menü neu zuordnen und die Tastaturbelegung von 
Befehlen ändern, auch wenn diese Tastaturbefehle nicht in 
Menüs oder Dialog-Fenstern erscheinen. Der Anwender 
kann hierfür einfach in einer Liste blättern, die er im Edit- 
Menü findet. Daraus läßt sich jeder Befehl auswählen und 
einer bestimmten Tastenkombination oder einem Menü 
zuordnen. 

Neben der größeren Flexibilität, die Microsoft Word 4.0 
bietet, verfügt das Programm auch über neue Funktionen, 
die die Textverarbeitung schneller und einfacher als bisher 
machen. Eine neue Tabellenfunktion erzeugt beispielsweise 
ein einstellbares Liniennetz, mit dessen Hilfe spaltenorien- 
tierte Absätze, Daten in Form von Kalkulationstabellen 
sowie Grafiken und Texte einfach positioniert werden kön- 
nen, ohne Tabulatoren setzen zu müssen. Zur Gestaltung 
und Hervorhebung lassen sich außerdem Rahmen, Unter- 
streichungen und Linien einsetzen. 

Die Fixierung von Objekten an definierten Stellen 
erleichtert die Erstellung eines Seiten-Layouts. Mit der 
Absolut-Positionierfunktion können Anwender Grafiken 
oder Teile des Textes an definierten Stellen auf einer Seite 
verankern. Zusätzlicher Text fließt dann um die fixierten 
Objekte herum, ohne sie zu ändern, auch wenn im Text 
selbst Korrekturen vorgenommen werden. 

Microsoft Word 4.0 verfügt über neun »hot spot«-Berei- 
che auf dem Bildschirm, in denen der Anwender durch ein 
Doppelklicken der Maus Funktionen aufrufen kann. Erfah- 
rene Anwender sind damit in der Lage, Seiten durch- 
zublättern, Fußnoten einzufügen, Tabulatoren zu verän- 
dern, Dokumentfenster zu teilen und anderes mehr. Solche 
direkten Manipulations-Möglichkeiten über das grafische 
Bediener-Interface des Macintosh’ sind Beispiele dafür, in 
welcher Weise Microsoft Word 4.0 die Möglichkeiten des 
Macintosh nutzbar macht. 

Mit Hilfe des AutoMac-III-Makroprogramms, das 
Bestandteil von Microsoft Word 4.0 ist, können Anwender 
jede Sequenz von häufig verwendeten Befehlen automatisie- 
ren. Darüber hinaus bietet die neue Version ein Wörter- 
buch mit 220.000 Wörtern sowie eine integrierte Wörter- 
Zählfunktion. 

Verbesserte Funktionen 


Als Reaktion auf den Wunsch zahlreicher Word-Anwender 
unterstützt die Version 4.0 nun sowohl eine automatische 
wie eine Batch-Repaginierung. Anwender, die auf 
schnellstmögliche Verarbeitung Wert legen, werden Word 
im Batch-Repaginierungs-Modus einsetzen. Die Automatik- 
Repaginierungs-Option ist dagegen für diejenigen hilfreich, 
die zu jeder Zeit den aktuellen Seitenumbruch sehen 
möchten. Im Seitenbetrachtungs-Modus (PageView Mode) 
stellt Microsoft Word 4.0 nun editierbare Spalten auf dem 
Bildschirm dar. 

Eine höhere Geschwindigkeit bei einer geringeren 
Anzahl sichtbarer Seitenelemente auf dem Bildschirm ist 


das wesentliche Merkmal des »Galley«-Modus (Galley 
View). Um die Entwicklung und Anwendung von Gestal- 
tungsmustern (style sheets) zu verbessern und zu erleich- 
tern, bietet Microsoft Word 4.0 Gestaltungsbeispiele (style 
by example). Dabei werden im »Outline view« alle Forma- 
tierungen auf dem Bildschirm dargestellt. Inhaltsverzeich- 
nisse und Indextabellen lassen sich durch die Markierung 
der entsprechenden Textteile automatisch erstellen, so daß 
auch diese Arbeit mit Microsoft Word 4.0 erleichtert wird. 


Das Zusammenspiel mit anderen Anwendungen 


Da die meisten Macintosh-Anwender mehrere Software- 
Pakete einsetzen, hat Microsoft vor allem auch der Integra- 
tionsfähigkeit von Word 4.0 große Aufmerksamkeit 
geschenkt. Die »Word QuickSwitch«-Funktion nutzt das 
Macintosh-Betriebssystem, zum Aufruf und Laden einer 
zweiten Anwendung (derzeit Microsoft Excel), wobei dann 
eine automatische Dateiverbindung hergestellt und auf- 
rechterhalten wird. So ist es beispielsweise möglich, grafi- 
sche Darstellungen oder Tabellen, die mit Microsoft Excel 
erstellt wurden, in ein Textdokument zu laden, um sie dort 
auf einfache Weise zu ergänzen und zu aktualisieren. 

Integrale Bestandteile der Microsoft Word-Umgebun- 
gen sind Microsoft Mail, Microsoft File und Microsoft 
PowerPoint. Auf Microsoft Mail kann von Word 4.0 aus 
zugegriffen werden, um Dokumente, die mit allen verfüg- 
baren »style sheets« formatierbar sind, zu empfangen oder 
zu senden. Zusammen mit Microsoft File eingesetzt, ist 
Mailmerge erheblich einfacher anzuwenden, weil Word alle 
Mailmerge-Felder in einer File-Datenbank anzeigt. Word 
und PowerPoint arbeiten mit demselben Format für vom 
Anwender erstellte Wörterbücher, so daß Wörterbücher 
mit speziellen Begriffen sowohl für die Erstellung von Tex- 
ten als auch für Präsentations-Dokumente genutzt werden 
können. 

Microsoft Word 4.0 für den Macintosh setzt als System- 
basis einen Macintosh Computer mit 512 Kbyte RAM und 
zwei 800 Kbyte Floppy-Disk Laufwerken oder eine Fest- 
platte voraus. Das Programm ist kompatibel mit Apple- 
Share und MultiFinder. 

Microsoft Word 4.0 für den Macintosh ist in der deut- 
schen Version voraussichtlich Ende März 1989 verfügbar 
und kostet ca. 1.268 DM (zzgl. MwSt.). Die englische Ver- 
sion wird bereits Anfang März 1989 zu einem Preis von ca. 
936 DM (zzgl. MwSt.) im Handel sein. 


Januar/Februar 1989 Microsoft System Journal 55 


Mitteilungen 


Mitteilungen .... Mitteilungen .... Mitteilungen 


Programmiertools für die Benutzeroberfläche 


Aspen Scientific (USA) hat die Firma Kickstein Software 
(Augsburg) mit dem deutschen Exklusiv-Vertrieb ihrer Pro- 
grammierertools beauftragt. Der Schwerpunkt des Sorti- 
ments liegt auf Tools für die Entwicklung von portablen 
Benutzeroberflächen zwischen MS-DOS, OS/2 und UNIX. 
Die Produktpalette umfaßt Tools wie Curses für MS- 
DOS und OS/2, Formation für MS-DOS, OS/2 und UNIX. 
Mit diesen Tools sind Programmentwickler in der Lage, 
ohne großen Aufwand moderne und ausgereifte Benutzer- 
oberflächen zu entwickeln, und diese zwischen MS-DOS, 
OS/2, UNIX oder XENIX zu portieren. Beide Produkte 
werden in den USA schon seit Jahren erfolgreich von 
namhaften Firmen eingesetzt. Kickstein Software 
unterstützt die Aspen Scientific Produktpalette durch 
technischen Support und deutsche Dokumentation. 


Curses, der Fenstermanager aus der Unix-Welt 
jetzt unter MS-DOS und OS/2 


Aspen Scientifics Curses ist eine komplette Portierung von 
Curses unter Unix System V.3 auf MS-DOS oder OS/2. Da 
der neueste Curses-Standard abwärtskompatibel mit älteren 
Curses-Versionen ist, kann man mit Apsen Scientifics Cur- 
ses Programme sowohl von Berkely UNIX 4.2 und 4.3 BSD 
als auch von XENIX portieren. 

Curses ist das Unix-Programmierwerkzeug zur Ent- 
wicklung von Benutzeroberflächen. Mit dem Curses-Paket 
können C-Programmierer nun Programme, die Curses ver- 
wenden, von Unix auf MS-DOS oder umgekehrt übertra- 
gen. Gleichermaßen steht dem Entwickler der komplette 
mächtige Befehlsumfang von Curses für Entwicklungen in 
einer MS-DOS Umgebung zur Verfügung. Curses arbeitet 
geräteunabhängig, d.h. ein Entwickler braucht ein Pro- 
gramm nur einmal zu schreiben um es dann unter allen MS- 
DOS-Bildschirmschnittstellen laufen zu lassen. 

Curses unterstützt derzeit folgende Adapter: EGA (inkl. 
43-Zeichen-Modus), CGA, MDA, BIOS Farb- und Mono- 
chromanzeige sowie ANSI-Bildschirmsteuerung in Farbe 
und monochrom. Curses ist sehr schnell, denn es arbeitet 
mit derselben Bildschirmoptimierung wie Unix-Curses. 

Im Lieferumfang von Curses sind zusätzlich die Bild- 
schirmmaskenverwaltung FAST (mit Quelltexten), das 
Online-Hilfesyttem QuickHELP und der interaktive C- 
Quellencodegenerator, Editor und Interpreter TUTOR 
enthalten. Mit TUTOR schreibt man sein erstes Curses- 
Programm bereits nach wenigen Minuten. 

Das Handbuch von Curses ist zur Zeit noch in englisch, 
ein deutsches Handbuch ist in Arbeit. Curses ist für alle 
gängigen C-Compiler, z.B. auch Microsoft C, erhältlich. 

Curses ist ab sofort als Binärpaket (Funktionsbiblio- 
theken) mit TUTOR, FAST und QuickHELP zum empfoh- 
lenen Verkaufspreis von DM 298,- inkl. MwSt. oder mit 
allen Curses-Quelltexten zum empfohlenen Verkaufspreis 
von DM 720,- inkl. MwSt. lieferbar. 
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Formation, der Fenster-, Menü- und Dialogboxen-Manger 
unter Curses für MS-DOS, OS/2 und UNIX 


Mit Aspen Scientifics Formation steht dem Softwareent- 
wickler ein mächtiges Werkzeug für eine moderne Benut- 
zeroberfläche zur Verfügung. Es eröffnet ihm im Text- 
modus Möglichkeiten, die er sonst nur in einer grafischen 
Umgebung hat. Anders als bei herkömmlichen C-Fenster- 
biliotheken, unterstützt Formation sogenannte »Viewports«, 
große virtuelle Fenster (sogenannte »Pads«), Pop-Up-, 
Drop-Down- und Balken-Menüs, Dialogboxen und vieles 
andere mehr. In einem Formation »Viewport« kann man 
eine Menge verschiedenster Operationen wie Scrollen, 
Einfügen und Löschen von Zeilen und Zeichen, Attribute 
ändern, Zeichen schreiben und wiederholen, Linien und 
Boxen zeichnen und vieles mehr durchführen. Formation 
verwaltet automatisch die Wiederherstellung von sich 
überschneidenden »Viewports«. 

Dem Entwickler stehen drei verschiedene Menüschnitt- 
stellen zur Verfügung: Pop-Up-, Drop-Down- und Balken- 
Menüs. Mit ihren Dialogboxen ist Aspen Scientific einen 
anderen Weg als die vielen zeichenorientierten Fenstertools 
gegangen. Sie besitzen mehrere Arten von Eingabemedien: 
scrollende Eingabefelder, Zusatzknöpfe, Checkboxen, 
serollende Übersichtsboxen und Befehlsknöpfe. 

Zusätzlich ist im Lieferumfang von Formation noch das 
Online-Hilfesystem QuickHELP enthalten. Das Handbuch 
ist zur Zeit noch in englisch, eine deutsches Handbuch ist 
jedoch bereits in Arbeit. Formation ist für alle gängigen C- 
Compiler, zum Beispiel auch Microsoft C, erhältlich. 

Um eine 100%ige Portabilität zu erreichen, baut For- 
mation auf Aspen Scientifics Curses auf. So kann ein Pro- 
grammierer jederzeit seine Anwendungen auf alle Systeme 
portieren, welche die Curses-Schnittstelle unterstützen (wie 
z.B. UNIX, DOS und OS/2). 

Formation ist ab sofort als Binärpaket (Funktionsbiblio- 
theken) mit QuickHELP zum empfohlenen Verkaufspreis 
von DM 398,- inkl. MwSt. oder mit allen Formation-Quell- 
texten zum empfohlen Verkaufspreis von DM 748,- inkl. 
MwSt. lieferbar. Eine Demodiskette ist für einen Unkosten- 
beitrag von DM 10,- bei Kickstein Software, Augsburg, er- 
hältlich. 


Cursor Datei Stri Top Ende 
ORmATIoN [1] en rl 


Hachr| Der CURSES Fenster/Menü Manager 
L Es is| Viele Besonderheiten, plus 


Zeit- und Galdersparais sind t Ihre Vorteile! 


Dro| Drücken Sie die Nummer (1-5) des 
L-M] "Viewports' der zu oberst sein soll. 


WICHTIG! 


Kurzkritik........ Kurzkritik....... Kurzkritik 


Von 3,5" auf 5,25" und umgekehrt 


Das Problem ist bekannt: Der AT, mit dem man 
arbeitet, kann keine 3,5-Zoll-Disketten lesen 
bzw. das PS/2-Modell keine 5,25-Zoll-Disketten. 
Abhilfe schaffen hier die beiden kleinen 
»Kisten« von Sysgen, genannt Bridge-File, die in 
Deutschland von M+S Elektronik vertrieben 
werden. 


Das externe Bridge-File gibt es in der 5,25-Zoll-Version 
(360 Kbyte und 1,2 Mbyte) für die PS/2-Modelle 30, 
50/50Z, 60/80 und 70 sowie in der 3,5-Zoll-Version (720 
Kbyte und 1,44 Mbyte) für die PC-Modelle bis zum AT. 
Beide kosten einschließlich Adapter und Mehrwertsteuer 
1345,20 DM. 

Die Installation des 3,5-Zoll-Laufwerks, das uns zum 
Test zur Verfügung stand, war denkbar einfach. Eine kurze 
Karte wird in die Zentraleinheit gesteckt und über ein mit- 
geliefertes Kabel zwischen den bereits vorhandenen Disk- 
Controller und das eingebaute 5,25-Zoll-Laufwerk ge- 
schleift. Die Verbindung zum externen Bridge-File wird 
über ein dickes Kabel mit zwei gleichen 37-poligen Steckern 
hergestellt. 

Nun muß noch die Software-Installation vorgenommen 
werden. Auf der beigelegten 5,25-Zoll-Diskette befinden 
sich dazu ein Install-Programm und zwei Treiber. Nach 
Aufruf dieses Programms wird zunächst einmal der benutz- 
te Computer ausgewählt (Bild I). Sind dann auch die übri- 
gen Fragen beantwortet, werden die Angaben zur Über- 
prüfung angezeigt (Bild 2). Durch die Bestätigung mit »Y« 
kopiert das Installationsprogramm den richtigen Treiber auf 
das gewünschte Laufwerk und trägt in die Konfigurations- 
datei diesen Einheitentreiber ein. 

Jetzt kommen die beiden Utilities zur Anwendung. Mit 
VIEW kann man sich den Laufwerksbuchstaben anzeigen 
lassen, mit dem das neue Laufwerk anzusprechen ist. Die 
zweite Utility, FORMAT35, dient zum Vorbereiten der Dis- 
ketten. Abhängig vom Schalter /F:3 oder /F:4 wird die 
3,5-Zoll-Diskette mit 720 Kbyte bzw. 1,44 Mbyte formatiert. 


Bridgefile Install Utility v2.51 
ale 1987, 1988, a Inc. 


Select the computer system to install : 


BR Be (SEHE cr Henn 
8560-041) or 80 dee 


IBM AT or compatible 
IBM PC/XT or compatible 


D the_arrow to move 
s <ENTER> Due 


Bild 1: Die Installation beginnt mit der Auswahl des Compu- 
termodells. 


File Install Utility v2. ar 
c) 1987, 1988, Sysgen, Inc 


Coogrighe 


Installing : 
1 External 2 


i “ un IA ÄTor AT or compatibl 
” an or e 
t drive C: 


Is this correct ? Y 


Bild 2: Zur Kontrolle werden noch einmal die ausgewählten 
Daten angezeigt. 


Fazit 


Weder das Laufwerk, noch die Installation machten irgend- 
welche Probleme. Nicht zuletzt aufgrund des ausführlichen, 
jedoch englischen Handbuchs. Schade ist eigentlich nur, daß 
Bridge-File keine Macintosh-Disketten verarbeiten kann. 

nı 


Buchkatalog auf Diskette 


Einen Elektronik-Fachbuch-Katalog als Datenbank auf 
Diskette bietet die Firma Feltron-Zeissler an. Diese mit 
Clipper realisierte Anwendung bietet auf inzwischen vier 
360-Kbyte-Disketten über 4200 Titel der wichtigsten deut- 
schen Verlage zur Auswahl an. 

Die Daten können entweder nach der Bestellnummer, 
oder einem Stichwort durchsucht werden. Wird z.B das 
Stichwort »Word« gewählt, erscheinen nacheinander die 
Word-Titel mit den in Bild 3 dargestellten Informationen. 

Eine solche Buch-Disk ist fast kostenlos. So werden die 
ersten drei Disketten für unglaubliche 7,20 DM inklusive 
Versandkosten angeboten. Natürlich macht Feltron-Zeissler 
das nicht ganz uneigennützig und bietet gleich die schnelle 
Auslieferung der gewünschten Bücher innerhalb eines 
Tages an. Ein Service also, der gerade auf dem »flachen 
Lande« nicht zu unterschätzen ist. 

nı 


FELTRON Literaturverwalt v2.2 
= -. r liefern ee 


Gesamt-Bestand: 4357 gegen 

aktueller Rec.: 4 420 tl schnellstens 111 
Auslieferung meist 
„mach Bestellei 


ae 02241/41004 
TELEX: 889476 zeiss d 


Suchen nach Stichwort: <WORD 
Bestellnummer: 
Titel ; 
Preis 


Text: Gibt jn Jeichtverständlichen, alphabetisch geordneten Abschnitte 
x; kunft über säntliche Fähigkeiten von Word. 


NT90621 

Kiemeier H. Add Marianne 
WORD-4.0- 

ya S. 


<4>=WEITER <t > = ZURÜCK Abbruch wit <ESC>... 


Bild 3: Bei der Suche nach »Word« erscheinen außer Word- 
Büchern auch Titel zu Wordstar oder Word Perfect. 
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Termine 


Termine 


Mit Microsoft-Seminaren sicher in die Zukunft 


Das Betriebssystem der Zukunft heißt Microsoft OS/2. 
Microsoft Windows und der Presentation Manager sind die 
Benutzeroberflächen der Zukunft. Für professionelle Ent- 
wickler bedeutet das, sich ab sofort mit dieser neuen Soft- 
ware auseinandersetzen müssen. Damit schaffen sie die 
Voraussetzung, schnellstmöglichst Programme in der 
»neuen Welt« verfügbar zu haben. 

Natürlich wird die Umstellung auf das neue Betriebs- 
system sowie die Programmerstellung nicht von heute auf 
morgen vollzogen sein. Um den Anfang jedoch so einfach 
wie möglich zu gestalten, bietet Microsoft eine Dienstlei- 
stung an: Das Microsoft Institut. 

Die Spezialseminare des Microsoft Instituts vermitteln 
in kleinen Gruppen intensiv all das, was zum Einstieg in die 
Programmentwicklung nötig ist. Modernste Trainings- 
methoden sowie PC-Demonstrationen und -Übungen sind 
selbstverständlich. Die Dozenten befassen sich auch im per- 
sönlichen Gespräch ausführlich mit den individuellen For- 
derungen und Problemen der Teilnehmer. So bekommen 
professionelle Entwickler durch professionelle Schulung die 
Möglichkeit, ihren hohen Wissenstand den neuen Gegeben- 
heiten anzupassen. 

Jeder Interessent in der Bundesrepublik Deutschland, 
der Schweiz und Österreich hat die Chance, sich mit der 
neuen Welt von Microsoft OS/2 und Microsoft Windows 
auseinanderzusetzen. Denn das Microsoft Institut arbeitet 
vor Ort mit kompetenten Schulungsunternehmen zusam- 
men: 


Digicomp AG, Zürich 

Elektro-Calcul PI S.A., Lausanne 

Integrata GmbH, Tübingen 

INTEL Semiconductor GmbH, Feldkirchen/München 
Olivetti Bildungs-Zentrum GmbH, Düsseldorf 
Ueberreuter Media GmbH, Wien. 


Die Dozenten werden speziell von Microsoft ausgebildet 
und stehen in ständigem Kontakt mit uns. So gibt es keine 
Informationsverluste: Das Wissen wird immer aktuell und 
aus erster Hand vermittelt. Microsoft erstellt die Seminare 
und die Seminarunterlagen und gewährleistet Qualität 
durch die Auswertung der Seminare. 


Das Microsoft OS/2 Einführungs-Seminar 


Das zweitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmierkenntnisse in einer höheren Pro- 
grammiersprache wie C, Pascal, o.ä. besitzen. 

Die Teilnehmer lernen im Vortrag und in Diskussionen 
das Konzept von Microsoft OS/2 kennen und erhalten 
einen Überblick über die Fähigkeiten und Programmier- 
schnittstellen dieses Betriebssystems. Während des Semi- 
nars haben die Teilnehmer die Möglichkeit, das Gelernte 
anhand von Übungsaufgaben für sich selbst zu überprüfen. 
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... Termine ... Termine ... Termine 


Ort Datum Veranstalter 
Düsseldorf 16./17.01. OBZ 
13./14.02. OBZ 
06./07.03. OBZ 
Graz 15./16.03. Ueberreuter 
Hamburg 06./07.02. Integrata 
09./10.03. Integrata 
Innsbruck 12./13.01. Ueberreuter 
Lausanne 13./14.02. Electro Calcul 
Linz 23./24.01. Ueberreuter 
Salzburg 13./14.03. Ueberreuter 
Wien 20./21.02. Ueberreuter 
Zürich 30./31.01. Digicomp 


Der Microsoft OS/2 Workshop 


Das dreitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmiererfahrungen in einer höheren, 
strukturierten Programmiersprache unter MS-DOS und C- 
Kenntnisse besitzen sowie das MS-OS/2-Einführungssemi- 
nar besucht haben. 

Die Teilnehmer lernen im Vortrag und praktischen 
Übungen am PC Family-API-Programme zu schreiben und 
Device-I/O-Routinen zu erstellen sowie Multitasking-Funk- 
tionen zu nutzen und eigene Dynamic-Link-Bibliotheken zu 
erstellen; außerdem können sie die erweiterten Speicherver- 
waltungsmöglichkeiten des Intel 80286 nutzen und mit Hilfe 
des MS-OS/2 Memory Managers programmieren. Dieses 
Seminar ist übrigens nicht im SDK-Preis enthalten. 


Ort Datum Veranstalter 
Düsseldorf 18./19./20.01. OBZ 
15./16./17.02. OBZ 
08./09./10.03. OBZ 
Frankfurt 25./26./27.01. Integrata 
Hamburg 08./09./10.02. Integrata 
Lausanne 22./23./24.02. Electro Calcul 
Tübingen 29./30./31.03. Integrata 
Wien 11./12./13.01. Ueberreuter 
01./02./03.03. Ueberreuter 
Zürich 06./07./13.03. Digicomp 


Das Microsoft Windows Einführungs-Seminar 


Das zweitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmierkenntnisse in einer höheren Pro- 
grammiersprache wie C, Pascal, o.ä. besitzen. 

Die Teilnehmer lernen im Vortrag und in Diskussionen 
das Konzept von Microsoft Windows kennen und erhalten 
einen Überblick über dessen Fähigkeiten und Program- 
mierschnittstellen. Dieses Seminar ist nicht im SDK-Preis 
enthalten. 


Termine 


. 
Termine 
Ort Datum Veranstalter 
Düsseldorf 23./24.01. OBZ 
20./21.02. OBZ 
13./14.03. OBZ 
Frankfurt 06./07.03. Integrata 
Innsbruck 06./07.02. Ueberreuter 
Lausanne 06./07.03. Electro Calcul 
München 13./14.02. Integrata 
Salzburg 13./14.03. Ueberreuter 
Wien 26./27.01. Ueberreuter 
Zürich auf Anfrage Digicomp 


Der Microsoft Windows Workshop 
Das dreitägige Seminar wendet sich an PC-Software-Ent- 


... Termine ... Termine ... Termine 


Microsoft Excel für Programmierer 


Das dreitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmiererfahrung in einer höheren Pro- 
grammiersprache haben. 
Die Teilnehmer lernen im Vortrag und in praktischen 
Übungen am PC das Konzept und die Möglichkeiten, mit 
Microsoft Excel-Makros Applikationen zu erstellen. 


Ort 


Düsseldorf 


Genf 
Hamburg 
Tübingen 
Wien 


Datum 


30./31.01./01.02. 
27./28.02./01.03. 
20./21./22.03. 
05./06./07.12. 
20./21./22.02. 
16./17./18.01. 
01./02./03.02. 
13./14./15.03. 


Veranstalter 


OBZ 

OBZ 

OBZ 

Electro Calcul 
Integrata 
Integrata 
Ueberreuter 
Ueberreuter 


wickler, die Programmiererfahrungen in einer höheren, 
strukturierten Programmiersprache unter MS-DOS und C- 
Kenntnisse besitzen sowie das Microsoft Windows Einfüh- 
rungsseminar besucht haben. 

Die Teilnehmer lernen im Vortrag und praktischen 
Übungen am PC Benutzerschnittstellen zu erstellen, die 
grafische Programmierschnittstelle zu nutzen, die Routinen 
zum Memory Management anzuwenden und dynamische 
Bibliotheken zu erstellen und zu benutzen. Dieses Seminar 
ist nicht im SDK-Preis enthalten. 


Microsoft Presentation Manager für Windows 
Programmierer 


Dieses Seminar erleichtert das Umsteigen von Microsoft 
Windows auf den Microsoft OS/2 Presentation Manager. 

Der Teilnehmer lernt die Unterschiede zwischen 
Microsoft Windows und dem Microsoft OS/2 Presentation 
Manager kennen und lernt, wie er seine Windows-Applika- 
tionen auf den PM übertragen kann. 


Ort Datum Veranstalter 
Düsseldorf 25./26./27.01. OBZ 
22./23./24.02. OBZ 
15./16./17.03. OBZ 
Frankfurt 08./09./10.03. Integrata 
Lausanne 08./09./10.03 Electro Calcul 
München 15./16./17.02. Integrata 
Wien 22./23./24.02. Ueberreuter 
Zürich auf Anfrage Digicomp 
BKS-Software 61 
BSP Krug 23 
Data Becker 9 
ECO Institut 73 
Interest Verlag Beilage 
Kickstein Software % 
Markt & Technik Buchverlag 84/85, 92 


46/47, 70/71 
61 


Ort Datum Veranstalter 
Düsseldorf 30.01.89 OBZ 

02.03.89 OBZ 
Frankfurt 31.01.89 Integrata 
Lausanne 14.03.89 Electro Calcul 
München 20.02.89 Integrata 
Tübingen 17.03.89 Integrata 
Wien 25.01.89 Ueberreuter 


Europa ’92 kommt ! 


Wir setzen 
MS Pascal, 


Ihre Source 


Programme 


C, Assembler und Turbo 


compilierfertig und fachmännisch um nach: 


Englisch, Französisch, Spanisch, Italienisch. 


Profisoft Gmbh 06150 83317 
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Assembler 


Allgemeingültige Zeichenwandlung und Klassifizierung: 
Nützliche Zeichenroutinen in Assembler 


In fast allen Programmen benötigt man Routi- 
nen, die Zeichenvergleiche oder die Einordnung 
von Zeichen in Zeichenklassen ermöglichen 
(alphanumerisch, Ziffer usw.). In den meisten 
Programmiersprachen sind <olche Routinen ent- 
halten, z.B. isupper(), tolower() in C. Der Assem- 
blerprogrammierer muß sich so etwas selbst 
bauen. Hier wird eine allgemeingültige Lösung 
dafür vorgestellt. 


Das Herzstück der gezeigten Routinen sind drei Tabellen: 
CType enthält Informationen über die Zeichenklasse, z.B. 
Klein- oder Großbuchstabe, Ziffer usw. 
CConv enthält für Großbuchstaben an der entsprechenden 
Zeichenposition die Kleinbuchstaben und umgekehrt. Diese 
Tabelle wird für Groß-/Kleinwandlungen benötigt. 
CLex enthält für jedes Zeichen seinen lexikalischen Wert. 
Damit können Zeichen unabhängig von ihrer Position im 
Zeichensatz lexikalisch richtig sortiert werden. 

Das Programmodul IS (Listing I) enthält folgende Bei- 
spielroutinen: 
IsDigit prüft, ob das Zeichen in AL eine Ziffer ist. 
Handelt es sich um eine Ziffer, wird das Carry-Flag gesetzt. 
IsDigit führt den Vergleich noch auf traditionelle Weise 
direkt durch. Das ist bei Ziffern kein Problem. Besser wäre 
hier jedoch eine Vorgehensweise, wie sie in der folgenden 
Routine zu sehen ist. 
IsAlpha prüft, ob das Zeichen in AL aphanumerisch ist 
(Groß- oder Kleinbuchstabe). Ist das Zeichen alphanume- 
risch, wird das Carry-Flag gesetzt. IsAlpha geht zur 
Bestimmung der Zeichenklasse über die Tabelle CType. 
ToUpper wandelt das Zeichen in AL in einen Großbuch- 
staben, wenn es sich um einen Kleinbuchstaben handelt. 
ToUpper geht zur Feststellung der Zeichenklasse über die 
Tabelle CType und wandelt dann das Zeichen über CConv. 
ToLex erhält ein Zeichen in AL und gibt seinen Sortierwert 
aus der Tabelle CLex in AL zurück. 

In der Art dieser Routinen kann man nun sehr einfach 
weitere Zeichenwandlungs- und klassifizierungroutinen 
schreiben, wie zum Beispiel IsUpper, ToLower usw. 


; Modul IS 
; (C) 1989 Günter Jürgensmeier 
„DATA 
; uppercase Großbuchstabe 
; lowercase Kleinbuchstabe 
; digit Ziffer 
; white space Leerzeichen, Tab usw. 
; punctuation Satzzeichen 
; control Steuerzeichen 
Liniengrafikzeichen 
hexadezimale Ziffer 


Up 
LO 
DG 
WS 
PU 
ct 
BO 
HX 


; box 
; hex digit 
Listing 1: Zeichenroutinen in Assembler 
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; CType: Tabelle für Zeichenart: UP LO DG WS PU CT BO HX 


Sr +++ Hr Herr 
333393393333 3393393393339333333939333393 


++++++ +++ + 


Im + zum 


++ +++ ++ +++ 
BZZZRERSSSE 
+4 ++ +++ +++ 
EEEEREESEEE 
& 
"ODOSANEUD-MÄN: 


+ +++ ++ 
BERRER 


) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 


m. —— ee m m et u a en a a m m a we nn m m a m a ne m a ne en 


B2WD-BVOD SAV AU DD 
HZONMOUNWIDBDVHM N 


Listing 1: (Fortsetzung) 


i t für 
OLWARE st das Konz bos m 


BKS -TO \ va 
triebssystem! 
a. Fordern Siea 


Listenerstellung U 


Profi-Tools für 
QuickBASIC 


Schreiben Sie schnellere, leistungsfähigere und 

professionellere Programme! Wir helfen Ihnen 

dabei mit nützlichen Tools. 

Zum Beispiel: 

® Toolboxen (Fenstertechnik, Menüs, 
DOS-Funktionen etc.) 

® Relationale Datenbank mit komfortablem 
Masken-Editor 

© Grafik-Paket (Geschäftsgrafik und 
Zeichensatz-Generator) 

® Maus-Unterstützung für Ihre Programme 

Alle Pakete mit ausführlich dokumentierten 

Quelltexten und Programmbeispielen. Wo erfor- 

derlich, kommen schnelle Assembler-Routinen 

zum Einsatz. Wollen Sie mehr aus Ihrem BASIC- 

Compiler herausholen? Wir informieren Sie 

gerne kostenlos! 


Ingenieur-Büro Harald Zoschke 


Berliner Str. 3, D-2306 Schönberg/Holstein 
Telefon 04344/6166 


Eingetr. Warenzeichen: QuickBASIC: Microsoft; 


usführliche | 


_ Präzisionsw® 
BKS-TOOLWARF 1 Gr afik-Program 


NEU 


Mehr Freiraum 
im 386’er, 
trotz CodeView. 


MagicCV - der 
Geheimtip 

für 
Programmierer 


Mit MagicCV passen 
jetzt auch umfangreiche 
Applikationen und 
CodeView in den Spei- 
cher. Komprimieren Sie 
CodeView auf 8K. Neu- 
gierig? Dann Info anfor- 
dern - oder MagicCV 
gleich bestellen für nur 
DM 685,-. 


CodeView/Reg. Trademark Microsoft 
MagicCV ist ein Produkt der Nu Mega Technologies. 


PEM 

Dipl.-Ing. T. Basien 
Plieninger Str. 100/11 
7000 Stuttgart 80 
Tel.: 0711/7280495 
Fax.: 0711/7280382 


Greifen Sie für uns zur Feder! 


Wir suchen schreibfreudige Experten. 


Wenn Sie Ihr Wissen über Programmierung oder über Standard-Anwendungen nicht für sich be- 
halten und daraus Kapital schlagen wollen, wenden Sie sich an uns. Wir suchen ständig Autoren 
für das Microsoft System Journal und mehrere Buchreihen renommierter deutscher Fachverlage. 


Redaktionsbüro Hartmut Niemeier, Theresienstr. 40, 8000 München 2, © (089) 23 48 00 


Gibt es preiswerter Informationen, 
als die Erfahrungen* von Fachleuten zu nutzen? 


*z.B. unsere Fachübersetzung MS Windows Programmer's Reference! ——(# 


Weiterhin bieten wir: 

« 5 tägige Schulungen MS Windows-Training and Practice 
(ab 6 Teilnehmer auch in Ihrer Firma) Versandkosten \ | 

« Windows Programmierung nur \ \ ’ \ 

» qualifizierte Fachübersetzungen Ihrer Software-Dokumentation Yy ped| 
in englisch, französisch und spanisch pm 286,— MD 


Incl. \ 
MwSt. plus \ 


pcd Pirwitz Computer Dokumentation GmbH - 2300 Kiel 1 - Eckernförder Straße 259 - Tel.: 0431/54 20 70 
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wo=na,n 


STEETETETTETITEITTSTSS 


7 
7 
7 
7 
7 
88 
81 
82 
83 
84 
8 
8 
8 
8 
8 
I 
9 
9 


zz MIN<KESCHNDIO VDOZET 


Dom 00 AIon\n 


+ 
+ 
“ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
“ 
u 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 


BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 
BO 


[in ee 


mu nu u. u un u u uuuuuvuuvuuuuouuuuuugvuuuuuuunuuuu nun uvuuuvuvuvvuvuvuvvvuuvuvuvuuuuuuuvuvvvuvuvuveun 


Listing 1: (Fortsetzung) Listing 1: (Fortsetzung) 
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Assembler 


Art tttrtr rt HH HH HH 
SELZZLLLZLELLLELEE 


BGH ‚BB1H,AB2H,ORSH, DB4H, BB5H,BO6H, BOTH 
BBeH , DB9H, ORah, AdbH, DfcH, BBdH, BdeH, dAfH 
B10H,811H,012H,013H,814H,815H,B16H,817H 
B18H,819H,D1aH,B1bH,BicH,B1dH,DleH,B1fH 
826H,,821H,022H,823H, 24H, 825H ,826H,827H 
228H,229H,22aH, @2bH, 82cH, 82dH ‚Ö2eH ,d2fH 
Ö30H ,831H,032H,,033H, 034H,035H,,836H,,837H 
838H,039H,23aH, 03bH,03cH, B3dH, B3eH, B3fH 
B40H,861H,262H ,263H,064H,865H,,B66H ,B67H 
868H ,869H,86aH, B6bH,A6cH, A6dH,B6eH,d6fH 
87H, 871H,272H,873H, 874H,875H,,076H,,877H 
878H,879H,87aH, 85bH, 85cH, B5dH,B5eH,B5fH 
B6BH,B41H,942H, 8434, 844H,D45H ,Q46H ,D47H 
B48H,049H, Q4aH,B4bH, B4cH, B4dH,,B4eH,B4fH 
850H ,851H,2052H, 853H, 054H, 055H ,056H,,857H 
058H,859H,, 05aH, 87bH,87cH, 87dH,B7eH, 87H 
887H,89aH, B98H,285H, B8eH, B85H, BBfH, B8dH 
288H, 89H, 88aH, Q8bH, BBcH, B8dH, 984H, B86H 
882H,292H,891H,893H, B99H,,895H , B96H , B9I7H 
B98H, B94H,B81H,BIbH, B9cH, BIdH, B9eH, BIEH 
BaßH,BaiH,da2H,da3H, Ba5H,Ba4H, Ba6H, Ba7H 
Qa8ßH,Qa9H,BaaH,BabH, Bach, BadH, BaeH,BafH 
dbEH,Bb1H,db2H,2b3H,2b4H, Bb5H,Bb6H,Bb7H 
£b8H, Bb9H, 2baH,BbbH, dbcH, ZbdH,BbeH,dbfH 
dcdH,dciH,ßc2H,Bc3H,dc4H,Bc5H,Bc6H,Bc7H 
dc8H, Bc9H,BcaH,dcbH, BccH, BcdH, BceH,dcfH 
BdEH,Ad1H,Ad2H,Bd3H, Ad4H, Bd5H,Ad6H, Bd7H 
2d8H,Ad9H,ZdaH, BdbH, BdcH, BddH,BdeH,BdfH 
BeßH,BeiH,de2H, Be3H, fe4H, Be5H,De6H, Be7H 
BeßH,de9H,BeaH,BebH,BecH, BedH,BeeH,defH 
BfAH,BfIH,Af2H,Qf3H, Af4H, Bf5H,Bf6H, BETH 
DfSH, DE9H BfaH,BfbH,BfcH,BfdH,BfeH,dffH 


[aFTSSSIEEESEESESEESSSSSSESSESSSESSSESESs ss asgmessacnenneennnnn 


CLex ; 


b 
’ 
’ 
’ 
bi 
D 
’ 
’ 
; 
’ 
’ 
’ 
’ 
’ 
’ 
’ 


Listing 1: (Fortsetzung) 


; IsDigit : prüft, ob Zeichen in AL eine Ziffer ist 


Public IsDigit 
IsDigit Proc Near 
al,'g’ 
IsDi it_No 


c al,' 
*f IsDigit_No 


> 
IsDigit_Yes: 
stc 


ret 
IsDigit_No: 

clc 

ret 
IsDigit EndP 


[ESEESESESSSSSSSEESEEZESSEEIESEIBEREEEREEEESTRRESTEETESSEISSIESE 


; IsAlpha : prüft, ob Zeichen in AL alphanunerisch ist 


Public IsAlpha 
IsAlpha Proc Near 
push ax 
bx 
bl,al 
bh,bh 
al,Byte Ptr CTypelbx] 
SDR 
x 


ax 
z IsDigit_No 
ap IsDigit_Yes 
IsAlpha EndP 


; ToUpper : wandelt Zeichen in AL in Gropbuchstaben 


Public ToUpper 
Tolpper Proc Near 
h bx 
bl,al 
bh,bh 
Byte Ptr CType[bx],LO 
rRet 


al,Byte Ptr CConv[bx] 
bx 


ToUpper EndP 


; : wandelt Zeichen in AL in lexikalischen Wert 


bl,al 

bh,bh 

like Ptr CLex[bx] 
x 


Listing 1: (Ende) 
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Schleife: D 


Buffer ‚BufSize,STDIN ; von STDIN lesen 
ds . 


name UPPER 
e 65,132 
itle StdIn auf StdOut in Großbuchstaben ausgeben 


ReadErr ; Lesefehler 

ax,ax ; Daten gelesen ? 
Exit ; Nein --> 
ReadSize,ax ; AX = Anzahl Bytes 
CX,ax ‚ nach CX 


; Handle STDIN 
; Handle STDOUT 
; Handle STDERR 


Cvt ; konvertieren 


ds F 
Buffer ‚ReadSize ,STDOUT; 
s ä 


WriteErr ; Schreibfehler 

Schleife ; weiterlesen bis Dateiende 
; PufferOffset ; 

; Pufferseguent 

; Puffergröße 

; Anzahl gelesene Bytes 


; Flag Anführung 


: Beenden, kein Fehler 


; Fehler beim Lesen 
ReadMsg,ReadLen,STDERR ; Fehler auf STDERR 
2 ; Beenden mit Fehler 2 


UPPER 1.88 2 (C) 1989 G. Jürgensmeier 
Gibt Eingabe in Großbuchstaben aus 


Bedienung: 
<Eingabedatei >Ausgabedatei 
Die Zeichen < und > vor den Dateinamen 
müssen eingegeben werden, da sonst auf 
Tastatureingaben gewartet wird. Dies 
kann mit "Z oder F6 abgebrochen werden. 


; Fehler beim Schreiben 
WriteMsg,WriteLen,STDERR ; Fehler auf STDERR 
3 ; Beenden mit Fehler 3 


Handelt im Segment "BufSeg” in der Länge CX 
alle Klein- in Gropbuchstaben, wenn sie 
nicht in Anführungszeichen stehen. 


equ $-StartNsg 


"UPPER: DOS-Version zu alt.”,13,18,7 
$-DosMsg 
"UPPER: Fehler beim Lesen.”,13,18,7 
u | 
"UPPER: Fehler beim Schreiben."”,13,18,7 
Writelen equ $-KWritelisg 


„CODE 


Üpper: 


es 
ax,BufSeg 
es,ax 
si,d 

mov ax,@data 

mov ds,ax 

eli 

mov SS,ax 

mov sp,Offset STACK 
sti 


Daten-Segmentreg. init. 
al,es:[si] 
Interrupte aus 

SS und 

SP relativ zu DGROUP Fl ; 
Short CvtLoopEnd; 


Jap 
CvtNQuote: 5 
cap QFlag,d ; nur außerhalb Anf. 
konvertieren 
jne CvtLoopEnd ; 


Speicherverwaltung einrichten 


Stapelzeiger in Par hen 
A halt 


mov bx,sp 
um Stapelgröpe zu e en 


mov cl,4 
shr bx,cl 
add ax,bx 
mov bx,es 
sub ax,bx 
@ModBlok ax 


@GetBlok AFFFh 
mov BufSeg,ax 
mov cx,4 

shl bx,cl 

mov BufSize,bx 


&GetVer 


SS addieren = Progranmende 
Beginn des Progranns 

Start von Ende abziehen 
Speicher über Prg freigeben 
Speicher für Puffer zuweisen 
Versuchen, 64 K zu bekommen 
Puffer-Segment speichern 


call ToUpper $ 
mov ByterPir es:[si],al 


in echte Länge umwandeln 
wirkliche Ag speichern 
DOS-Version überprüfen 
DOS feststellen 

cap al,2 DOS 2.8 wird benötigt 


jge Banner 

DOS-Version zu alt 
@Write DosMsg,DosLen,STD) ; Fehler auf STDERR 
eExit 1 ; Beenden mit Fehler 1 


Cvt 


m. 


INCLUDE is.asıa 


; Startmeldung ; 
end Upper 


“ @hrite StartMsg,StartLen,STDERR 


Listing 2: Das Beispielprogramm ToUpper Listing 2: (Ende) 
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Microsoft Symposium 


Bilder einer Ausstellung: 


Hard- und Softwareperspektiven 1989 


Erstmals veranstaltete Microsoft anstelle der 
bislang üblichen Herbst-Roadshow für seine 
Partner ein zentrales Symposium. Fachhändler, 
Distributoren, Großkunden, Softwareentwickler 
und Kollegen aus dem Hardwarebereich hatten 
Gelegenheit, am 28. November 1988 in Frankfurt 
am Main anerkannte Fachleute zu Strategien 
und technologischen Perspektiven unserer 
Branche für die nächsten Jahre zu hören und zu 
befragen. Unbestrittener Höhepunkt jedoch war 
die Ausstellung, auf der knapp zwei Dutzend 
Aussteller marktreife Anwendungen für Micro- 
soft Windows und Microsoft Excel vorführten. 


Excel: Software des Jahres 


Das Jahr 1988 war ein Windows-Jahr. Nicht nur, daß sich 
die im Vorjahr eingeführte Version 2.0 dieser MS-DOS- 
Betriebssystemerweiterung auf dem Markt schnell durch- 
setzen konnte, mit Microsoft Excel betrat auch die erste 
große Standardanwendung aus dem Haus Microsoft die 
Windows-Bühne. Dieses Tabellenmanagementprogramm 
war die erste Anwendung, die die Leistungsfähigkeit von 
Windows richtig ausspielen konnte. Als Tabellenmanage- 
mentprogramm mit integrierten Grafik- und Datenbank- 
funktionen gelang es Excel binnen weniger Monate, zum 
Inbegriff einer neuen Softwaregeneration zu werden. Kein 
anderes Tabellenkalkulationsprogramm war wie Excel in 
der Lage, Kritiker zu begeistern. Dynamischer Datenaus- 
tausch mit externen Anwendungen, professionelle Layout- 
und Darstellungsmöglichkeiten, bislang unbekannte Funk- 
tionstiefe, ausgereifte Hilfe- und Computer Based Training- 
Module und eine Makrosprache, die Amateuren eine 
schnelle Anpassung an individuelle Anforderungen und 
Profis die Erstellung komplexer Branchenlösungen ermög- 
licht - das waren die vielbesprochenen Highlights. So errang 
Excel zahlreiche Preise und Auszeichnungen sowohl in den 
USA als auch in Deutschland. Erst vor wenigen Wochen 
wählten die Redaktionen zehn europäischer PC-Fachzeit- 
schriften Microsoft Excel zur Software des Jahres. In 
Deutschland machte Excel Microsoft schon zwei Monate 
nach Auslieferung zum größten Spreadsheetanbieter. 

Der Erfolg von Excel verdankt sich aber nicht nur der 
technologischen Überlegenheit des Produkts. Alle haben an 
diesem Erfolg mitgeholfen: Handel, Schulungshäuser und 
Entwickler. Zahlreiche Marketingaktionen wurden zur 
Markteinführung durchgeführt. Der Distributor Computer 
2000 bundelte sein Above-Board mit Excel. Die Zeitung PC 
Magazin organisierte für Entwickler einen Programmier- 
wettbewerb für Excel-Anwendungen. In zahlreichen Fach- 
geschäften warben die Excel-Plakate von Microsoft. Das 
Harlekin-Motiv errang als Zeitungsanzeige Preise für krea- 
tives Marketing. 


BILD 1: Rund zwei Dutzend Aussteller zeigten in Frankfurt 
ihre Anwendungen auf der Basis von Microsoft Windows oder 
Excel. 


Bild 2: Fachsimpeln am Rande der Ausstellung: Emil 
Widmer (links), Inhaber der Schweizer »Computertechnik für 
Manager« im Gespräch mit Mitarbeitem der Microsoft 
GmbH, unter ihnen Karin Paul (rechts), Leiterin Sales Distri- 
butors bei Microsoft. 


Windows hat sich durchgesetzt 


Excel ist aber nicht nur ein erfolgreiches Produkt. Es wirbt 
auch mit seiner Existenz für Microsoft Windows. Windows 
ist - endlich! - ins Gerede gekommen, und zwar im positiven 
Sinn. Die Version 2.0 hat viele Mängel der alten Version 1.x 
ausgeräumt. Windows ist schneller und flexibler geworden. 
Windows 386 schließlich konnte sich zum Standard unter 
den Betriebssytemerweiterungen für 386er Rechner ent- 
wickeln. Seine Multitaskingfähigkeiten bewegten viele 
Hardwarehersteller dazu, Windows 386 gleich mit ihren 
Rechnern zusammen auszuliefern. Compaq, IBM, Zenith, 
Victor, um nur einige zu nennen, führten erfolgreich solche 
Aktionen durch. Unterstützt wurde der Erfolg von Windows 
sicherlich durch die Diskussion um MS OS/2, das neue 
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Bild 3: Gregory Gordon, Microsoft-Produktmanager für Mac- 
intosh-Software, erläuterte an seinem Informationsstand dem 
Publikum Ähnlichkeiten und Unterschiede zwischen den 
Excel-Versionen für MS-DOS unter Windows und den Mac- 
intosh-Rechnern. 


Bild 4: Meist dicht umlagert: Der Stand von Siemens Öster- 
reich, auf dem Computer Aided System Engineering mit dem 
Windows-Produkt EasyCASE demonstriert wurde. 


Betriebssystem von Microsoft und IBM. MS OS/2 bzw. 
BS/2, wie es bei IBM heißt, wird in der Version 1.1 zusam- 
men mit dem Presentation Manager ausgeliefert werden. 
Dieser Presentation Manager wird das gleiche Gesicht 
haben wie Microsoft Windows. Die Bedieneroberfläche der 
neuen Version 4.0 von MS-DOS kommt als drittes System 
hinzu. Damit haben es Anwender künftig bei zeichenorien- 
tierten Programmen unter MS-DOS, bei grafikorientierten 
MS-DOS Windows-Applikationen und bei MS OS/2-Appli- 
kationen unter dem Presentation Manager mit der gleichen 
Oberfläche zu tun. Mit dem Presentation Manager/X, im 
November 1988 angekündigt, können sich sogar UNIX- 
Anwender diesem Anwenderkreis anschließen. Typischer 
»Macintosh-Komfort« fand durch Windows Eingang in die 
Welt des Industriestandards. 
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Bild 5: Frank Utermöhlen, Microsoft Produktmanager für 
Compiler, zeigte neueste MS-OS,/2 Compilertechnologie. 


Bild 6: Gerhard Rutkowski, Leiter von der Abt. Officeland der 
Münchner Softwareschmiede Softlab bei einer kleinen Ener- 
giespende für den Düsseldorfer Microsoft-Mitarbeiter Lothar 
Splittstösser. 


Diese Perspektive hat sicherlich viele Anwender im 
vergangenen Jahr bewogen, auf Microsoft Windows umzu- 
steigen. Heute werden jeden Monat weltweit mehr Win- 
dows-Packungen verkauft als Macintosh-Rechner. 

Und auch Systementwickler wandten sich verstärkt 
Windows zu. Die gemeinsamen Programmierschnittstellen 
von Windows, Presentation Manager und Presentation 
Manager/X erlauben ihnen die Erstellung von Anwendun- 
gen, die sich ohne größere Umbaumaßnahmen für MS- 
DOS, MS OS/2 und UNIX anpassen lassen. Und selbst der 
Schritt zu Macintosh-Anwendungen ist für den Windows- 
Entwickler ein Katzensprung. Eben dies bewiesen die Aus- 
steller auf dem Frankfurter Microsoft Symposium. Kaum 
einer von ihnen entwickelt ausschließlich für Windows. Fast 
jeder hat zugleich MS OS/2 oder den Macintosh im Visier. 


Microsoft Symposium 


Bild 7: Dr. Michael Müller, Leiter des Großkundenvertriebs 
bei Microsoft, im Gespräch mit Barbara Fischer, die 
Microsofts Kunden in der Schweiz betreut. 


Bild 8: Technologische Avantgardeleistungen waren am CD 
ROM-Stand von Bertelsmann zu begutachten. 


Die Aussteller 


Zu den renommiertesten Ausstellern zählte sicherlich die 
österreichische Siemens AG. In Wien hat man schon lange 
Erfahrungen mit Microsoft Windows sammeln können. So 
wurde mit EasyCASE ein Produkt vorgestellt, daß seine 
Markteinführung gerade vor sich hat, seine Marktreife aber 
schon auf der Ausstellung hinlänglich beweisen konnte. 
Dabei handelt es sich bei EasyCASE eigentlich um drei 
Programme. EasyCASE (SD) unterstützt das System Desig- 
ning mit Kommunikationsplänen, EasyCASE (DD) bildet 
ein Data Dictionary für Standardauswertungen, und Easy- 
CASE (SP) erleichtert als Editor strukturiertes Program- 
mieren mit Struktogrammen. 


Bild 9: Einen Blick auf die brandneue nächste MS OS/2- 
fähige Version 5.0 von Microsoft Word konnten Besucher am 
Stand von Karin Süsser, Produktmanagerin für Textverarbei- 
tung bei Microsoft, riskieren. Bis zur Marktreife und Ausliefe- 
rung freilich bleiben noch einige Wochen Zeit. 


Bild 10: Ein CAD-System mit integrierter Datenbank auf 
Windows-Basis wurde auf dem Stand von CAS gezeigt. 


Entwickler mit MS OS/2-Ambitionen versammelten 
sich um den Microsoft Compiler-Stand. Dort konnte man 
sich BASIC-, FORTRAN-, C-, Assembler- und Pascal- 
Compiler für MS OS/2 ansehen. Die größte Aufmerksam- 
keit freilich erregte der neue Microsoft COBOL 3.0-Com- 
piler. Ihn hatte Microsoft erst wenige Tage zuvor erstmals 
in Deutschland vorgestellt. Dabei handelt es sich um eine 
Gemeinschaftsentwicklung von Microsoft und Micro Focus. 

Zu den renommierten Entwicklern, die zugleich für 
Windows und den Presentation Manager programmieren, 
gehört die Firma Softlab. Dieses Unternehmen, das in 
Deutschland zu den bedeutendsten Entwicklern von Bran- 
chenlösungen gerechnet wird, nutzt vor allem die SAA- 
Schnittstellen von Windows, mit denen ein Übergang zu den 
Mini- und Großrechnern der IBM-Welt geschaffen wird. 
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Bild 11: Informationsgespräch auf dem Stand der Manage- 
ment Software AG. 


Bild 12: Kevin P. Welch, Präsident der Eikon Systems, über- 
nahm auf seinem Stand selbst die Regie. 


Auf lange und erfolgreiche Arbeit mit Windows-Pro- 
dukten kann die Firma GCA verweisen, die ebenfalls mit 
einem eigenen Stand auf der Frankfurter Messe vertreten 
war. Derzeit unternimmt sie eine Vielzahl von Marke- 
tinganstrengungen, um das Produkt »Accessories No.1« im 
Markt zu etablieren - und wie es scheint, mit großem 
Erfolg. Die Accessories sind eine Sammlung von Zusatz- 
produkten, die Windows-Anwendern das Leben leichter 
machen können. So lassen sich eigene Menüs mit grafischen 
Symbolen für unterschiedlichste Dateien anlegen. Mit dem 
Bridge-Modul kann man GEM-Formate in Windows 
umsetzen. Ein anderes Modul erlaubt die Anfertigung von 
Scereencopies. Weitere Programme erhöhen die Daten- 
sicherheit, erleichtern die Druckerkontrolle, bieten eine 
digitale Bildschirmuhr und ermutigen den Spieltrieb von 
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Bild 13: Christian Wedell, Geschäftsführer der Microsoft 
GmbH, läßt sich von Peter Tewes von der Firma MICRO 
SERVICE eine Excel-Anwendung erklären. 


Bild 14: Ralf Klocke, Microsoft Verkaufsleiter für den Händ- 
lervertrieb, war ein gefragter Mann auf der Ausstellung. 
Schließlich waren »seine« Händler zahlreich erschienen. 


Windows-Anwendern. Neu war das Programm FORM 
MASTER auf dem GCA-Stand. Mit FORM MASTER las- 
sen sich Formulare anfertigen und komfortabel bearbeiten. 
Dabei werden eine Vielzahl von Formatierungsmöglichkei- 
ten geboten. Von diesem Produkt werden in den nächsten 
Wochen sicherlich noch zahlreiche Testberichte in der ein- 
schlägigen Fachpresse zu lesen sein. 

Für viele Besucher überraschend war der Auftritt von 
Bertelsmann auf der Ausstellung. Bertelsmann gilt in der 
Branche als Vorreiter der CD ROM-Technologie. Bisher 
wurden unter anderem folgende Anwendungen dieser 
neuen optischen Speichertechnologie vorgestellt: Washing- 
ton Presstext (Informationen der US-amerikanischen 
Regierung), Liefern & Leisten (Das Deutsche Branchen- 
Fernsprechbuch), Silverdat (Datensystem für die Auto- 


Microsoft Symposium 


Bild 15: Vincenz Wirth (links hinten), Leiter der Produkt- 
managment-Gruppe für Systemsoftware und Programmier- 
sprachen bei Microsoft, mußte zahlreichen Besuchern Rede 
und Antwort zum gerade fertiggestellten MS OS/2 Presenta- 
tion Manager stehen. 


mobilwirtschaft), Lauer-Taxe (Datenbank für den pharma- 
zeutischen Bereich), Wer liefert was? (Bezugsquellennach- 
weis für den Einkauf), Die Bibel, Lawbase (Entscheidungen 
des Schweizer Bundesgerichts), Twixtel (Schweizer Tele- 
phonbuch), Datenbank Leitverzeichnisse (Orts- und Stra- 
Benverzeichnis der Deutschen Bundespost und Müllers 
großes Deutsches Ortsbuch). Was aber hat all das mit Win- 
dows zu tun? Ganz einfach: Seit 1988 unterstützt das 
Bertelsmann Retrieval (Zugriffs)-System COBRA Micro- 
soft Windows. Im Prospekt des BCB - Bertelsmann Compu- 
ter Beratungsdienstes heißt es denn mit Blick auf MS OS/2 
auch: 

»Seit 1988 können Ihre Anwendungen auch von Micro- 
soft Windows unterstützt werden. So realisieren wir bereits 
jetzt für Sie die Anbindung an künftige Standard-Betriebs- 
systeme und den Presentation Manager.« 

Das IBM Personal Publishing System wurde auf dem 
Stand der KD COMPUTER FORUM GmbH vorgeführt. 
Bei diesem DTP-Komplettpaket von Mother Blue handelt 
es sich ebenfalls um ein auf Microsoft Windows basierendes 
System. Die Hardware - Personalcomputer, Laserdrucker - 
kommt von IBM, das DTP-Programm von Aldus (Page- 
maker), die »Seele« von Microsoft: Windows. 

Die Pirmasenser Computer Anwendungs- und System- 
beratung CAS zeigte ihr neues Paket COSTING. 
COSTING nutzt die Windows-Oberfläche für ein inte- 
griertes Grafik-/Kalkulationsmodell. Es dient der Kosten- 
kalkulation in den CAD-Abteilungen der Schuh- und 
Bekleidungsindustrie. 

Je eine Windows-Applikation zur Auftragsbearbeitung 
bei Zimmereibetrieben und für Maler wurde von der EDV- 
Beratung THEOBALD vorgestellt. Dieses Unternehmen 
hat bislang rund 400 verschiedene Branchenlösungen ent- 
wickelt und vermarktet. Seit einiger Zeit befindet man sich 
nun im Umstieg auf die Windows-Entwicklung. 


Warum man bei THEOBALD trotz programmiertechni- 
scher Startschwierigkeiten auf Windows umgestiegen ist, 
konnte man am Stand erfahren: »Von den bis jetzt 30 
Anwendern möchte niemand das Programm missen. An- 
wender aller Altersschichten, bei älteren Anwendern hatten 
wir ursprünglich erhebliche Bedenken, kommen mit dem 
Programm prima klar. Programme mit konventioneller 
Bedieneroberfläche werden von diesen Kunden nicht mehr 
akzeptiert. Die Einarbeitung in das Programm ging bis auf 
drei Fälle schneller, als wir es von konventionellen Pro- 
grammen gleichen Leistungsumfangs her gewohnt waren. 
Als riesigen Vorteil sehen wir die quasi genormte Bedie- 
neroberfläche. Wenn man ein MS-WINDOWS Programm 
bedienen kann, kann man alle MS WINDOWS Programme 
bedienen.« Der Umstieg auf den Presentation Manager ist 
übrigens auch bei THEOBALD schon geplant. 

Eine komplette Windows-Programmbibliothek für das 
technische Laborwesen im Straßenbau wurde von der Firma 
bpi-Büro für Planung und Ingenieurtechnik gezeigt. Die 
verschiedenen Module dienen unter der einheitlichen Win- 
dows-Oberfläche zum Beispiel der Verwaltung des techni- 
schen Regelwerks und möglicher Rezeptkomponenten für 
bituminöse Mischgüter, der Eignungsprüfung solcher 
Mischungen, der Durchführung und statistischen Auswer- 
tung von Mischgutuntersuchungen und der Überwachung 
von Mineralstoffen und Bindemitteln - woran man 
unschwer erkennen kann, daß Microsoft Windows zum 
ungeahnten Wegbereiter für viele geworden ist! 


Was gab es noch zu sehen? 


= Die Firma Eikon Systems aus den USA gehört zu den 
ältesten Windowsanbietern. Sie konnte ein komplettes 

Sortiment von Produkten vorführen. 
= Das Terminplanungssystem »TIMEGRAF« von netnice 

& partner bewies die Eignung grafischer Oberflächen- 

systeme für Netzplanapplikationen. 
= »artus« von der Berliner Firma TRONY, entwickelt für 

die Nachbearbeitung gescannter Bilder. 
= Die Gesellschaft für angewandte Informatik aus Karls- 
ruhe zeigte Windows-Software zur Meßdatenerfassung. 
= Integrata und Olivetti Bildungszentrum stellten ihre 

Schulungsaktivitäten für Windowsentwickler und -an- 

wender vor. 

Natürlich gab es auch eine Reihe von Excel-Anwendun- 
gen zu begutachten. Immer mehr Windows-Entwickler 
greifen auf dieses Tabellenmanagementprogramm mit sei- 
ner entwickelten Makrosprache als Entwicklungstool 
zurück. Die Firma MICRO SERVICE zum Beispiel zeigte 
gleich mehrere Excel-Anwendungen, unter anderem zur 
Lagerverwaltung und zum Rechnungswesen. Bei MICRO 
SERVICE fährt man zweigleisig. Die in der Entwicklung 
erworbenen Excel- und Windows-Kenntnisse werden gleich 
in Excel-Schulungen und -Seminaren weitergegeben. 
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COBOL 


Microsoft COBOL 3.0 ist da: 


Die Brücke zwischen DOS, OS/2 und Mainframes 


Microsoft bietet ein neues leistungsfähiges 
Werkzeug zur Entwicklung und Wartung von 
Mainframe-Applikationen in einer PC-Um- 
gebung an: die Version 3.0 des optimierenden 
COBOL-Compilers. Der durch das »US Natio- 
nal Bureau of Standards« freigegebene Compiler 
entspricht dem ANSI 85-COBOL High Level- 
Standard. Er unterstützt den großen Speicher- 
bedarf bei Mainframe-Applikationen, erzeugt 
Code, der zehnmal schneller ist als derjenige von 
COBOL 2.2 und ist kompatibel mit den meisten 
Mainframe-, Mini- und Mikrocomputer- 
COBOL-Dialekten, einschließlich der IBM- 
Mainframe-COBOL-Compiler. 


Microsoft COBOL erlaubt zusammen mit MS-OS/2 die 
Übernahme von Großrechner-Applikationsprogrammen für 
den Einsatz in PC-Umgebungen. Durch die Kompatibilität 
von Microsoft COBOL 3.0 zu den meistverbreiteten Main- 
frame-, Mini- und Mikrocomputer-COBOL-Dialekten, zum 
Beispiel zu IBM VS COBOL-II, IBM OS/VS-COBOL, 
X/Open COBOL, Data-General-COBOL, RM/COBOL 
und Microsoft COBOL 2.2, kann der Entwickler ohne Pro- 
bleme von einer Umgebung in die andere wechseln. Diese 
Möglichkeit wird darüber hinaus noch dadurch unter- 
mauert, daß Microsoft COBOL 3.0 dem SAA (System- 
Applikations-Architektur)-Standard der IBM entspricht. 

Unter MS-OS/2 werden Applikationen unterstützt, die 
bis zu 16 Mbyte virtuellen Speicher adressieren. Diese 
Fähigkeit setzt die Software-Entwickler in die Lage, größte 
Mainframe-Applikationsprogramme auf Personalcompu- 
tern laufen zu lassen, ohne daß sie durch die bisherige Spei- 
cherbegrenzung unter MS-DOS eingeschränkt sind. 

Die leistungsfähigen Entwicklungswerkzeuge des Micro- 
soft COBOL 3.0 bilden einen kompletten Satz sowohl für 
MS-DOS als auch für MS-OS/2-Applikationen. 


" and char not = "y* 
call ee" 


displa, 
N BG Be a square type a number between 1 and 9* 
€ 


perfora new-move until kres; not = spaces 
Bose a ” question 

r' ind - 
Ai pe * reply 


2? 
83 
En 
85 
8 
8 
88 
8 
9% 
91 
92 
93 
9 
95 
9% 
9 
98 
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100 Playzet: 
Animate-TI ‚evel=01-Speed=5-Ins-Caps-Nus-Scroll 
Flshelp Bm F3«align FA=exchange era F6=look-up F9/FlOmword-</> Escape 
Step 60 Zoom next-If Perform Reset B Break Env Query Find Locate Text Do 0-9=speed 


Bild 1: Debuggen mit dem Animator von MS-COBOL 3.0. 
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Eingeschlossen ist dabei der ANIMATOR - ein Source- 
Level-Debugger, der ganz auf den COBOL-Programmierer 
zugeschnitten ist und Source-Level-Tracing, Backtracking, 
Breakpoints, DO-Statements, periodische Breakpoints und 
die Fähigkeit beinhaltet, einzelne COBOL-Anweisungen im 
Online-Modus direkt auszuführen (Bilder I und 2). Eben- 
falls Bestandteil der Entwicklungswerkzeuge ist der 
Microsoft-Editor, eine MS-DOS Real-Mode und MS-OS/2 
Protected-Mode-Editierumgebung mit vollständiger Rekon- 
figurierbarkeit sowie Makro-Unterstützung. 

COBOL 3.0 ist ein »Maschinencode«-Compiler, der 
sehr schnellen Code erzeugt. Applikationen, die mit Micro- 
soft COBOL 3.0 compiliert wurden, laufen zehnmal schnel- 
ler als Applikationen, die mit der Version 2.2 compiliert 
wurden. Die I/O-Geschwindigkeit ist um 30 Prozent höher. 

Gemäß dem ANSI 85 High-Level-Standard beinhaltet 
Microsoft COBOL 3.0 Funktionen zur strukturierten Pro- 
grammierung, wie In-Line-PERFORM, EVALUATE, 
Scope Terminator, negierte Bedingungen, INITIALIZE, 
Global-Referenzen und Referenz-Modifikationen; Funktio- 
nen, die zur Verbesserung der Software-Wartung beitragen. 
Als Teil der Sprachenfamilie für MS-DOS und MS-OS/2- 
Systeme unterstützt COBOL 3.0 das Aufrufen von Subrou- 
tinen, die in anderen Microsoft-Sprachen geschrieben wur- 
den. Der Compiler bietet außerdem die Möglichkeit, daß 
Applikationen, die unter MS-DOS geschrieben wurden, nun 
auf einfache Weise in gängigen LANs eingesetzt und weiter- 
entwickelt werden können. Durch die Einsatzfähigkeit von 
COBOL 3.0 unter MS-OS/2 lassen sich Anwendungen 
extrem einfach in diese neue Umgebung übernehmen und 
die Vorteile der virtuellen Speicherverwaltung sowie des 
Multitaskings nutzen. 


Strategische Zusammenarbeit mit Micro Focus 


Im Zusammenhang mit der Ankündigung des COBOL 3.0- 
Compilers gab Microsoft die strategische Marketing- und 
Software-Entwicklungs-Allianz mit Micro Focus bekannt, 
deren Ergebnis das Produkt ist. 
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Bild 2: Beim Debuggen stehen viele Befehle zur Verfügung. 


COBOL 


Message to request abort confirmation when the ABORT key is pressed. 

[Abort - Y/N? * er es A | 

If trailing spaces are hr as part of the text, put a quotation mark after 
the last space, For example R * will have two spaces after the R stored as 
part of the text. 

If no text is required, leave the field blank. 


ADISCE—Alter- Individual -Messages —— ——— Ins -Caps -Mum-Scroll 
FisHelp Escape 


Bild 3: Mit einem Konfigurationsprogramm kann das Bild- 
schirmmodul von MS-COBOL 3.0 angepaßt werden. 


Micro Focus ist eines der weltweit führenden Unter- 
nehmen in der COBOL-Technologie mit Firmensitzen in 
Newbury (England), Palo Alto (Kalifornien) und München. 
Die Zusammenarbeit mit Micro Focus wird die Position 
von COBOL in der Mikrocomputer-Entwicklungsszene 
stärken, weil Microsoft sein führendes Know-How bei Ent- 
wicklungswerkzeugen und moderner Software-Technologie 
und Micro Focus seine hervorragenden PC-COBOL-Pro- 
dukte einbringt, so daß der Anwender von den Stärken bei- 
der Unternehmen profitiert. 

»Microsoft COBOL 3.0 ist eine deutliche Demonstra- 
tion des Engagements von Microsoft in der DP/MIS-Welt«, 
so Christian Wedell, Geschäftsführer der deutschen 
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Microsoft GmbH, zur Ankündigung der neuen COBOL- 
Version. »Es ist sicher, daß die neue Generation der 
80286/80386-Personalcomputer eine lebensfähige Grund- 
lage für die Entwicklung von DP/MIS-Applikationen auf 
MS-DOS- und MS-OS/2-Systemen darstellt. Wir engagie- 
ren uns dabei mit einem Hochleistungs-COBOL-Compiler, 
der ein integraler Bestandteil unserer Familie von MS- 
DOS- und MS-OS/2-Sprachen und -Werkzeugen ist«, so 
Wedell. Und: »Die strategische Verbindung zwischen 
Microsoft und Micro Focus ist eine Zusammenführung der 
weltweit führenden COBOL-Technologie mit der führen- 
den Mikrocomputer-System-Technologie.« Die beiden 
Unternehmen bieten nun nach Meinung von Wedell eine 
Entwicklungslösung für das größte Segment von Entwick- 
lern innerhalb der Software-Branche: die COBOL-Appli- 
kationsentwickler. 


Daten und Fakten 


Microsoft COBOL 3.0 wird bereits ausgeliefert. Für Besit- 
zer der Version 2.2 hält Microsoft ein Upgrade-Angebot 
bereit. Der neue Compiler läuft auf IBM-PCs oder 100%- 
Kompatiblen unter MS-OS/2 und MS-DOS (3.0 und 
höher). Systemvoraussetzungen sind ein doppelseitiges Dis- 
ketten-Laufwerk, ein Festplatten-Laufwerk und ein Haupt- 
speicher von 1,5 Mbyte (MS-OS/2) oder 384 Kbyte (MS- 
DOS). 
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Windows besser nutzen mit Expanded Memory: 


Leistungssteigerung durch EMS 


1981 führte IBM seinen Personalcomputer ein, 
der den Entwicklern von Anwendungssoftware 
unter anderem mehr Speicher zur Verfügung 
stellte. Sie werden sich sicher erinnern, daß die 
damals am meisten verkaufte Maschine der 
Apple II war, der mit seiner 6502-CPU 64 Kbyte 
Speicher adressieren konnte. Der Personalcom- 
puter von IBM war mit seinem Intel 8088- 
Microprozessor in der Lage, 1 Mbyte zu adres- 
sieren. Wenn man den für die Hardware reser- 
vierten Speicherbereich abzieht, war der Spei- 
cher von 640 Kbyte, der der Anwendung zur Ver- 
fügung stand zehnmal so groß, wie beim Apple. 
Plötzlich hatten Programmierer und Anwender 
mehr Speicher, als sie benötigten. 


Die Benutzer stießen an die Grenze von 640 Kbyte. Die 
Software wurde durch neue Möglichkeiten größer, Tabel- 
lenkalkulation und Textverarbeitung wuchsen durch die 
Anforderungen der Anwender, und durch die Fortschritte 
bei der Halbleiterfertigung sank der Speicherpreis. Was 
einst als eine ungeheure Größe erschien, war nicht mehr 
genug. 

Um den Anforderungen nach mehr Speicher gerecht zu 
werden, wurde 1984 die Expanded Memory Specification 
(EMS) eingeführt, um Anwendungen mehr als die 640 
Kbyte an Speicher zur Verfügung zu stellen. EMS definiert 
die Software-Schnittstelle zum Ansprechen von Expanded 
Memory. Unter Verwendung von EMS kann eine Anwen- 
dung bis zu 8 weitere Mbyte an Daten im RAM speichern. 
AST Research Inc. entwickelte eine Obermenge, die 
Enhanced Expanded Memory Specification (EEMS) genannt 
wird. Sie bietet größere Flexibilität in der Richtung, daß das 
Expanded Memory nur für den Gebrauch der Anwendung 
eingeblendet wird. 

Die EMS- und EEMS-Spezifikationen wurden von 
Lotus, Intel und Microsoft im August 1987 erweitert zur 
Expaned Memory Specification 4.0 (LIM EMS 4.0). EMS 
4.0 bietet bis zu 32 Mbyte Expanded Memory, also viermal 
mehr als die unter EMS 3.2 möglichen 8 Mbyte. Durch die 
Vereinigung zweier ähnlicher, aber doch unterschiedlicher 
Speicher-Spezifikationen bietet LIM EMS 4.0 eine verein- 
fachte Speicherunterstützung für Windows, da jede EMS- 
und EEMS-Karte zu LIM EMS 4.0 kompatibel gemacht 
werden kann, indem ein Treiber hinzugefügt wird. Neben 
der Vereinheitlichung der Expanded Memory-Schnittstelle 
bietet EMS 4.0 auch Multitasking-Unterstützung für Expan- 
ded Memory. 

Dieser Artikel beschreibt, wie Expanded Memory arbei- 
tet, wie Windows 2.0 Expanded Memory benützt, wie virtu- 
eller Speicher im Windows/386 implementiert ist, und wie 
die Unterstützung von Expanded Memory Ihre Windows- 
Programmierung beeinflussen kann. 
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Bild 1: EMS ermöglicht es dem Benutzer mehrere große 
“Anwendungen, wie Microsoft Excel und Aldus PageMaker, 
unter Windows laufen zu lassen. 


Expanded Memory 


EMS 4.0 erlaubt der Anwendung den Zugriff auf mehr als 
640 Kbyte Speicher. Hierzu wird ein Teil des 1 Mbyte- 
Adreßbereichs des 8088 als Fenster in das Expanded 
Memory verwendet. Dieses Fenster wird Seitenrahmen 
genannt. Abhängig von der Nutzung des Systemspeichers, 
reicht der Seitenrahmen von 16 bis 1024 Kbyte. 

Der Seitenrahmen ist in physische Seiten unterteilt, die 


"typischerweise 16 Kbyte groß sind. Das Expanded Memory 


ist in logische Seiten unterteilt, die ebenso 16 Kbyte groß 
sind. Die Anwendungen erhalten den Speicher, indem sie 
den Expanded Memory Manager (EMM) die Anzahl der 
benötigten logischen Seiten allokieren lassen. Die Anwen- 
dung muß den EMM einen Satz logischer Seiten in den 
physischen Adreßbereich einblenden lassen, bevor sie diese 
benutzen kann. Die Anwendung kann dann das Expanded 
Memory wie konventionellen Speicher benutzen. Beim 
Zugriff auf einen anderen Satz von logischen Seiten, muß 
der EMM diese vorher einblenden. Eine Anwendung kann 
auf keine Seite zugreifen, die nicht vorher eingeblendet 
wurde. Obwohl der physische Adreßbereich 1 Mbyte groß 
ist, kann das Expanded Memory bis zu 32 Mbyte groß sein. 
Bild 2 ist ein Speicherabbild, das die Beziehung einer 
MS-DOS-Anwendung, wie etwa Lotus 1-2-3, zu den logi- 
schen Seiten des Expanded Memory zeigt. In diesem Bei- 
spiel existieren zwei Rahmen im physischen Adreßbereich, 
genannt Rahmen 1 und Rahmen 2. Die zwei logischen Sei- 
ten, die Seite 3 und Seite 6 genannt werden, sind gerade in 
die beiden Rahmen eingeblendet. Beachten Sie, daß die 
doppelt umrandeten Bereiche für das Betriebssystem und 
die Hardware (z.B. den Bildschirmspeicher) reserviert sind. 
Der ganze Rahmen befindet sich oberhalb 640 Kbyte, 
obwohl EMS 4.0 es gestattet, daß das Expanded Memory 
überall in den physischen Adreßbereich eingeblendet wird. 


Windows 
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Bild 2: Dieses Speicherabbild zeigt eine MS-DOS-Anwendung 
wie Lotus 1-2-3, die Expanded Memory nach EMS 3.2 
benutzt. Die Rahmen 1 bis 4 bestehen aus jeweils 16 Kbyte 
physischem Speicher. 


Expanded Memory benötigt spezielle Hardware und 
spezielle Software. Die Hardware besteht aus einer Karte, 
die Speicherbausteine enthält. Die Software ist ein Einhei- 
tentreiber, der EMM heißt. Dieser bearbeitet die Anforde- 
rungen ans Expanded Memory und läßt die Speicherkarte 
das Ein- und Ausblenden durchführen. 

Die Anwendungen müssen durch einen Aufruf des 
EMM den Speicher allokieren, und durch einen anderen 
Aufruf diesen allokierten Speicher in den physischen 
Speicherbereich einblenden. Die dritte Aktion, die die 
Anwendung durchführen muß, ist das Freigeben des nicht 
mehr benötigten Speichers. Diese drei Schritte entsprechen 
den Aktionen, die beim Allokieren von Speicher von Win- 
dows ausgeführt werden. Speicher wird allokiert (entweder 
mit GlobalAlloc oder mit LocalAlloc), er wird in den 
physischen Adreßbereich eingeblendet (mit GlobalLock 
oder mit LocalLock), und er wird nach Gebrauch frei- 
gegeben (mit GlobalFree oder mit LocalFree). Der 


vierte Schritt, den Speicher auszublenden (GlobalUnlock 
oder LocalUnlock), ist in EMS Teil des Einblendeaufrufs. 

Einige EMS-Karten erlauben nur einen 64 Kbyte großen 
Block, der über der 640 Kbyte Grenze liegen muß. Andere 
Karten erlauben viele Seitenrahmen, ohne Beschränkung 
der Größe und der Lage. Obwohl der EMS-4.0-Einheiten- 
treiber für beide Kartentypen geschrieben werden kann, ist 
es doch notwendig, daß Windows beide unterschiedlich 
behandelt. Ältere Karten ließen den Bereich unter 640 
Kbyte unberührt und boten einen relativ kleinen Seiten- 
rahmen. Neuere Karten können so eingestellt werden, daß 
sie alles über 256 Kbyte belegen, was einen Bankbereich 
von über 600 Kbyte ergibt. 

Wie wir später sehen, beeinflußt die Rahmengröße die 
Art und Weise, wie die Speicherverwaltung von Windows 
das Expanded Memory benutzt. Ich werde in Zukunft die 
Version mit einem Rahmen als alte Version, und die mit 
mehreren Rahmen als neue Version bezeichnen. Auch kann 
das Vorhandensein von speicherresidenten Programmen 
(TSR, Terminate and Stay Resident), oder Netzwerkkarten 
oder anderer Anwendungen mit festem Speicher Windows 
veranlassen, neuere EMS-Karten im Modus mit kleinem 
Rahmen zu benutzen. 

Die Trennlinie zwischen dem umschaltbaren und dem 
nicht umschaltbaren Teil der gegebenen EMS-Konfigura- 
tion wird auch Umschaltlinie (bank line) bezeichnet. Die 
Kenntnis, wo Objekte angesiedelt werden, ob unter oder 
oberhalb der Umschaltlinie, beeinträchtigt Sie nicht, wenn 
Sie eine ausschließlich allein laufende Windows-Anwen- 
dung schreiben. Wenn Sie aber Anwendungen programmie- 
ren, die miteinander kommunizieren, Ihre eigene dynami- 
sche Linkbibliothek, Windows Hooks benutzen, oder die 
Zwischenablage bzw. DDE nutzen wollen, so sollten Sie 
sich mit der Position der Speicherobjekte relativ zur 
Umschaltlinie näher beschäftigen. 

Das Ein- und Ausblenden von logischen Seiten des 
Expanded Memory erfordert nicht das Kopieren großer 
Speicherblöcke. Statt dessen werden nur ein paar Register 
manipuliert. Nachdem diese Register beschrieben sind, ist 
der Speicher eingeblendet und kann so schnell und effizient 
angesprochen werden. 


Expanded Memory und Windows 


Windows Version 2.0 benutzt zum Zwischenspeichern von 
Anwendungen Expanded Memory. Durch diese Unterstüt- 
zung des Expanded Memory können große Anwendungen 
wie Microsoft Excel und Aldus PageMaker gleichzeitig 
laufen - in einer Geschwindigkeit, als wären sie nur allein 
vorhanden. Windows 1.x benutzte Expanded Memory, um 
typische MS-DOS-Anwendungen auszulagern, aber nicht 
für Windows-Anwendungen. Windows 2.0 unterstützt diese 
älteren Anwendungen, aber mit dem Vorteil, daß Windows- 
Anwendungen im Expanded Memory zwischengespeichert 
werden. 


Januar/Februar 1989 Microsoft System Journal 13 


Speicher ist die kostbarste Ressource unter Windows. Es 
gibt zwei Gründe dafür. Der eine ist die Hardware, der 
andere das spezielle Multitasking von Windows. Der Hard- 
waregrund ist einfach die Beschränkung des Arbeitsspei- 
chers des 8086-Prozessors auf 1 Mbyte. Das Multitasking 
von Windows benötigt unbegrenzt viel Speicher, wenn 
immer mehr Anwendungen laufen. Dieses Problem ist in 
Windows teilweise durch eine virtuelle Speicherverwaltung 
gelöst. Nicht benötigte Code- und Ressourcensegmente sind 
als entfernbar (discardable) markiert, und können nach 
einem »least recently used«-Algorithmus auf Anforderung 
freigegeben werden. Natürlich liest Windows diese, falls sie 
wieder benötigt werden, vom Massenspeicher (Code- und 
Ressourcensegmente sind nur lesbar, was bedeutet, daß der 
Inhalt auf dem Massenspeicher sicherlich korrekt ist). Das 
Speicherproblem läßt sich durch Entfernen nicht vollständig 
lösen. Jede Anwendung hat einen minimalen Speicher- 
bedarf, so daß zwei oder mehr große Programme nicht 
gleichzeitig laufen können. Dies ist ein Problem, da Anwen- 
der große Anwendungen am liebsten gleichzeitig laufen 
lassen, um Daten auszutauschen, DDE-Konversationen zu 
beginnen und um die Fähigkeiten von Windows zu nutzen, 
mehrere Programme gleichzeitig laufen zu lassen. 

Windows 2.0 löst dieses Problem mit seinem verbesser- 
ten Memory Manager, der jeder Anwendung seinen eigenen 
Speicher im Expanded Memory gibt, wodurch die Anwen- 
dung eigentlich allein auf der Maschine läuft. Dies funktio- 
niert immer, wenn eine EMS-Karte und ein EMS 4.0-Trei- 
ber vorhanden sind. Das Zwischenspeichern von Programm 
und Daten ist für Windows vollständig transparent. Der 
Windows-Speichermanager erledigt alle Aufrufe des EMM, 
um den Speicher zu allokieren, einzublenden, auszublenden 
und den Speicher wieder freizugeben, wenn die Anwendung 
beendet wird. 

Die Speicherverwaltung könnte verbessert werden, um 
den EMS-Speicher so zu verwalten, daß einer einzigen 
Anwendung die ganzen 32 Mbyte der EMS-4.0-Unterstüt- 
zung gegeben werden können. Die gegenwärtige Art wurde 
aus Implementationsgesichtspunkten, Geschwindigkeits- 
gründen und der Verfügbarkeit anderer Lösungen gewählt. 

Eine Überlegung war, daß Windows 2.0 aufwärtskom- 
patibel zu Windows 1.x sein muß. Das bedeutet, daß die 
Schnittstelle zur Speicherverwaltung gleich sein muß. Zum 
Benutzen des EMS-Speichers wäre eine neue Schnittstelle 
notwendig. Diese Schnittstelle existiert aber schon in der 
Form der EMS-4.0-Spezifikation. Wenn also eine Anwen- 
dung mehrere Mbyte an Speicher benötigt, kann sie diesen 
direkt von der EMS-Speicherverwaltung bekommen. 

Der zweite Grund für den gegenwärtige Entwurf ist die 
notwendige Geschwindigkeit bei der Unterstützung von 
Expanded Memory: dem gleichzeitigen Ablauf von mehre- 
ren großen Windows-Anwendungen mit einem minimalen 
Aufwand beim Kontextumschalten. Die derzeitige Imple- 
mentierung verlangt nur, daß jede Anwendung mit 640 
Kbyte in einer akzeptablen Geschwindigkeit arbeiten kann. 


76 Microsoft System Journal Januar/Februar 1989 


Es besitzt aber nicht jeder Computer Expanded Memory, 
und so kann ein Entwickler von Windows-Anwendungen 
diesen nicht voraussetzen. Nur beim Vertrieb einer Kom- 
plettlösung sieht dies anders aus. 

Der dritte Grund, weswegen Windows EMS-Unterstüt- 
zung nicht Mbyte von Expanded Memory für Anwendungen 
bietet, ist, daß ein Cache-Speicher das gleiche erledigt. Pro- 
gramm, Ressourcen und andere entfernbare Segmente 
können freigegeben und schnell mit der Hilfe der Möglich- 
keiten der Speicherverwaltung vom Disk Cache nachge- 
laden werden. Windows 2.0 beinhaltet ein Cache-Pro- 
gramm, das dynamisch EMS-Seiten allokiert und freigibt, 
ganz wie es gerade erforderlich ist. Im Gegensatz zu einer 
RAM-Disk ist die optimale Geschwindigkeit nicht von einer 
Benutzerentscheidung abhängig. 

Windows 2.0 läuft im Gegensatz zu früheren Versionen 
in der Kompatibilitätsbox von OS/2. Sogar in dieser 
Betriebsart benutzt Windows Expanded Memory. 


Arbeitsweise der EMS-Unterstützung 


Die Speicherverwaltung von Windows ist sowohl für die 
Kontrolle der dynamischen Allokierung des Speichers vom 
globalen Heap als auch für das Allokieren vom lokalen 
Heap für jede Task oder Bibliothek zuständig. Hier interes- 
siert uns nur die Allokierung vom globalen Heap. Die Spei- 
cherverwaltung von Windows bearbeitet Blockanfragen, 
indem sie die ganze Verwaltung erledigt wenn Blöcke ver- 
schoben oder entfernt werden müssen. Wenn ein Speicher- 
block wieder freigegeben wird, das heißt dem Speicherpool 
wieder zur Verfügung steht, merkt sich dies die Speicher- 
verwaltung. 

Windows blendet für jede Anwendung beim Laden eine 
neue Seite des EMS-Speichers ein. Bild 3 zeigt eine 
Speicherbelegung mit drei Windows-Anwendungen: Write, 
PageMaker und Microsoft Excel, jede in ihrem eigenen 
Bereich von Expanded Memory-Seiten. Im Bild 3 sind 
gerade alle Seiten von Microsoft Excel in den physischen 
Adreßbereich eingeblendet. Beachten Sie, daß nur die mini- 
mal benötigte Anzahl von logischen Expanded Memory- 
Seiten für eine Anwendung allokiert wird, wodurch das 
Expanded Memory sehr effizient genutzt werden kann. 

Bild 3 zeigt, daß alle Seiten von Microsoft Excel einge- 
blendet sind. Dies ist immer der Fall, wenn Microsoft Excel 
arbeitet, oder um bei der Terminologie von Windows zu 
bleiben: immer wenn Microsoft Excel eine Nachricht durch 
den Funktionsaufruf von GetMessage erhält. Klickt der 
Anwender das Fenster von PageMaker an, so wird durch 
eine Kontextumschaltung PageMaker zur aktiven Anwen- 
dung. Während der Kontextumschaltung blendet die Spei- 
cherverwaltung alle Seiten des Expanded Memory vom 
PageMaker ein, was bedeutet, daß alle Seiten von Microsoft 
Excel ausgeblendet werden. Das hat Auswirkungen auf den 
gemeinsamen Speicherzugriff von mehreren Anwendungen, 
was später erläutert wird. 
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Bild 3: Dieses Speicherabbild zeigt Code und Datensegmente 
der Programme Write, PageMaker und Microsoft Excel im 
Expanded Memory. Die Segmente von Microsoft Excel sind 
gerade in den physischen Adreßbereich der CPU eingeblendet. 


Während der Abarbeitung der Anwendung bleibt die 
Allokierung der Speicherbereiche fest. Das bedeutet, daß 
die Windows-Anwendungen in 640 Kbyte (in Wirklichkeit 
bis zu 256 Kbyte mehr, oder 896 Kbyte mit einer 64-Kbyte- 
EGA-Karte) laufen, und so programmiert sein sollten, daß 
sie innerhalb dieser Grenzen ein gutes Laufzeitverhalten 
zeigen. 

Die einzigen Objekte, die entfernt werden, sind diejeni- 
gen, die im physischen Adreßbereich liegen, das heißt, in 
einer der gerade eingeblendeten EMS-Seite oder unterhalb 
der Umschaltlinie. Viele Objekte, die ausgeblendet sind, 
werden nie entfernt. 


Speicherschutz 


Ist der EMS-Speicher einer Anwendung nicht in den physi- 
schen Speicherbereich eingeblendet, so ist er geschützt 
gegen »unsaubere Anwendungen«. Wenn Windows mit 


großen EMS-Rahmen läuft, wenn also Expanded Memory 
in jeden Teil des physischen Adreßbereichs eingeblendet 
werden kann, dann ist jede Anwendung vollständig von den 
anderen geschützt. Stehen nur kleine Rahmen zur Verfü- 
gung, dann sind nur diejenigen Programmteile, die im 
Expanded Memory stehen, geschützt. Obwohl dieser Spei- 
cherschutz nicht so gut wie der von OS/2 ist, bei dem uner- 
laubte Adressierung zu einer generellen Schutzverletzung 
führt, so gehen diese Schutzfähigkeiten doch weit über die- 
jenigen von Windows 1.x hinaus. 


Speicherverwalter 


Wenn Windows mit EMS-Speicher arbeitet, dann sind in 
Wirklichkeit zwei Speicherverwaltungen anwesend. Die 
Speicherverwaltung von Windows ist unter Windows 2.0 die 
primäre, sie ruft den EMM nur zur Kontrolle über das 
Expanded Memory auf. Seine Aufgabe ist das Allokieren, 
Ein- und Ausblenden sowie Freigeben des Expanded 
Memory. Ebenso muß er über die Register des EMS Buch 
führen. Da zwei Speicherverwaltungen vorhanden sind, 
kann eine Windows-Anwendung den EMM direkt zum 
Allokieren von Speicher ansprechen, wenn sie weiß, daß er 
vorhanden ist. 

Eine Sache, die Sie sicher gerne wissen möchten, ist, 
welche Objekte über der Umschaltlinie angelegt werden, 
und daher ausgeblendet werden können, und welche unter- 
halb dieser Linie liegen, und daher von mehreren benutzt 
werden können. Diese Diskussion ist schwierig, da EMS 4.0 
zwei Arten von Seitenrahmen unterstützt: kleine und große. 
Der kleine EMS-Seitenrahmen ist 64 Kbyte groß, der große 
hingegen kann bis zu 896 Kbyte groß sein - falls die Hard- 
ware es zuläßt. Da normalerweise der ganze Adreßbereich 
über 256 Kbyte bei der Verwendung eines großen Seiten- 
rahmens umgeschaltet werden kann, bietet diese Lösung die 
meisten Möglichkeiten für die Speicherverwaltung von 
Windows. Tabelle 1 zeigt, wie Expanded Memory bei beiden 
Typen von Seitenrahmen verwendet wird. 


Immer unter- oberhalb 
halb der Linie der Linie 
kleiner großer 


Rahmen Rahmen 


Datenbanken der Anwendung 
Modulheader (EXE) 
Bibliotheks-Datensegmente 
Fester Code in Bibliotheken 
Thunks 

Bibliotheksressourcen 
Codesegment der Anwendung 
Ressourcen der Anwendung 
Datensegmente der Anwendung 
Entfernbarer Bibliothekscode 
Dynamisch allokierter Speicher 
(über GlobalAlloc) Y 


Tabelle 1: Expanded Memory wird für beide Arten von Sei- 
tenrahmen benutzt. 
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Kommt eine Anwendung mehr als einmal vor, dann 
verwendet die gegenwärtige Implementierung eine Bank 
gemeinsam (obwohl jedes Vorkommen sein eigenes Daten- 
segment besitzt) und vermeidet so alle Probleme mit dem 
gemeinsamen Speicher, der entweder explizit durch Get- 
InstanceData oder implizit durch gemeinsame Speicher- 
handles verwaltet wird. Spätere Implementierungen könn- 
ten dem Entwickler die Option bieten, für jedes Vorkom- 
men einer Anwendung eine eigene EMS-Bank anzufordern. 

Sicher gibt ein großer Rahmen der Speicherverwaltung 
die größtmögliche Flexibilität, aber sogar mit einem kleinen 
Rahmen ergibt die EMS-Unterstützung große Vorteile. Bei 
kleinen Anwendungen paßt der gesamte Programm- und 
Ressourcenbereich in den eingeblendeten Speicher, und 
gestattet auf diese Weise vielen kleinen Anwendungen ohne 
Geschwindigkeitsverlust zu arbeiten. Anwendungen wie die 
Systemsteuerung, der Taschenrechner und der Kalender 
können mit einer großen Anwendung wie etwa Microsoft 
Excel zusammen und ohne große gegenseitige Beeinträchti- 
gung betrieben werden. Hier erlaubt sogar der kleine Rah- 
men eine bessere Ausnutzung der Multitasking-Fähigkeiten 
von Windows. 


Dynamische Linkbibliotheken 


Werden kleine Rahmen verwendet, werden nur die Res- 
sourcen und die Programmteile einer Task in den EMS- 
Speicher geladen. Hingegen legt die Speicherverwaltung bei 
großen EMS-Rahmen viele andere Objekte oberhalb der 
Umschaltlinie an. Dies beinhaltet Datensegmente der Task, 
entfernbare Bibliotheks-Programmteile und Speicher, der 
mit GlobalAlloc allokiert wurde. Die letzten beiden müs- 
sen mit Sorgfalt behandelt werden, da sich dadurch einige 
Implementierungsprobleme ergeben. 

Dynamische Bibliotheken können von jeder Task ange- 
sprochen werden. Dynamische Bibliotheken unter Windows 
sind zum Beispiel die Module Kernel, User und GDI, sowie 
alle Einheitentreiber (Tastatur, Maus, Timer, Bildschirm 
und Drucker). Es ist verständlich, daß Funktionen wie die 
GDI-Routine TextOut für jede Task ständig verfügbar sein 
müssen. Ist ein großer EMS-Rahmen verfügbar, so werden 
die Programmteile auf eine der beiden folgenden Weisen 
gehandhabt: Feste Programmteile liegen unter der Linie, 
entfernbare Programmteile liegen über der Linie. 

Bei der Unterstützung großer EMS-Rahmen werden 
entfernbare Segmente der Bibliotheken über die Umschalt- 
linie der Task gelegt, wodurch die Wahrscheinlichkeit steigt, 
daß ein Teil der Bibliothek zu jeder Zeit in mehreren Banks 
erscheint. Zum Beispiel können mehrere Kopien des Dia- 
logbox-Managers, der die Fensterprozeduren für die Edit-, 
Pushbutton- und andere Dialogbox-Steuerungen enthält, im 
EMS-Speicher vorhanden sein. Obwohl dies Redundanz be- 
deutet, haben die Anwendungen doch Zugriff auf die Funk- 
tionen, die sie benötigen. Außerdem wird wenig Platz im 
Speicher unter der Linie verbraucht. 
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Gewöhnlich erfolgt die Allokierung von Speicher durch 
eine dynamische Linkbibliothek in einem großen EMS- 
Rahmen oberhalb der Linie. Es gibt aber auch Fälle, in 
denen es für eine Bibliothek notwendig ist, ihren globalen 
Speicher unter dieser Linie zu haben. Einige Bibliotheken 
könnten globale Variablen verwenden, auf die sie immer 
zugreifen müssen. In diesem Fall wird beim Aufruf von 
GlobalAlloc das Flag GMEM_NOT_BANKED verwendet. 

Die Druckertreiber von Windows 1.x haben Kompatibi- 
litätsprobleme, da sie das GMEM_NOT_BANKED-Flag nicht 
benutzen. Druckertreiber sind die einzigen Bibliotheks- 
funktionen, die über die LoadLibrary-Funktion geladen 
werden. Andere Bibliotheken werden als »abhängige« 
Module von Tasks geladen. (Ein abhängiges Modul ist eine 
Bibliothek, die die Task zum Ablaufen benötigt.) Bibliothe- 
ken, die mit LoadLibrary geladen werden, allokieren glo- 
balen Speicher unter der EMS-Umschaltlinie. Abhängige 
Module hingegen allokieren globalen Speicher standard- 
mäßig über der Umschaltlinie. 


Änderungen des API 


Nur eine einzige zusätzliche Funktion, LimitEMSPage, 
wurde zum Windows-API (application programming inter- 
face) hinzugefügt. Diese Funktion gestattet es einer Anwen- 
dung, die Anzahl der Seiten, die Windows allokiert, zu 
kontrollieren. Sie begrenzt aber nicht die Anzahl der Seiten, 
die die Anwendung selbst vom EMS-Manager allokieren 
kann. 

Wollen Sie Windows ohne EMS-Speicher starten, so 
müssen Sie beim Start von Windows /n in der Kommando- 
zeile angeben: 
c>win /n 


Virtueller Speicher 


Der größte Vorteil von Windows/386 ist die Unterstützung 
von Standard-MS-DOS-Anwendungen. Die augenblickliche 
Version von Windows/386 erzeugt mehrere virtuelle 
Maschinen (VM), die sich alle wie unabhängige 8086-Rech- 
ner verhalten. Da jede seinen eigenen 8086 und 640 Kbyte 
Speicher zugeteilt bekommt, laufen die Anwendungen ohne 
sich gegenseitig zu beeinflussen. Da der 80386 die Möglich- 
keit besitzt, den direkten Bildschirmspeicherzugriff abzu- 
fangen, kann jede Anwendung in ihrem eigenen Fenster auf 
dem Bildschirm laufen. 

Bedenken Sie aber, daß Windows/386 nicht jeder Win- 
dows-Anwendung seinen eigenen Speicher von 640 Kbyte 
gibt. Statt dessen laufen alle Windows-Anwendungen in 
zusammen 640 Kbyte Speicher. Dies bedeutet, daß die 
Windows-Anwendungen unter Windows/386 nicht diesel- 
ben Speichervorteile haben, wie MS-DOS-Anwendungen. 

Die Unterstützung der Speicherumschaltung ist in Win- 
dows/386 dieselbe wie die EMS-Unterstützung in Windows 
2.0. Sie arbeitet allerdings ein wenig anders. Da der 386 


hardwaremäßige Unterstützung für die Speicherverwaltung 
bietet, sind die Unterschiede für die Windows-Anwendung 
transparent. 


Programmierrichtlinien 


Die hier dargestellten Programmierrichtlinien werden für 
einen Windows-Programmierer keine Überraschungen 
bieten. Sie sollen hier aber wiederholt werden, da die EMS- 
Unterstützung unter Windows 2.0 und die Unterstützung 
von virtuellem Speicher unter Windows/386 verlangen, daß 
diese Richtlinien genau eingehalten werden. Die Richtlinien 
gelten für beide Versionen, aber einige sind speziell für die 
EMS-Unterstützung bestimmt. Sie geben Ihnen die Gewiß- 
heit, daß Ihre Anwendung sowohl unter Windows 2.0 als 
auch unter Windows/386 läuft. 


Effiziente Speicherausnutzung 


Es gibt derzeit keine Pläne, eine Windows-Anwendung mit 
Hilfe der Windows-Speicherverwaltung Speicher über dem 
physischen Adreßraum von 1 Mbyte des 8086 allokieren zu 
lassen. Statt dessen führt Windows ein Einblenden von 
Speicher aus, so daß jede Anwendung glaubt, den ganzen 
Computer für sich zu haben. 

Die Speicherverwaltung von Windows gestattet Ihnen 
zur Laufzeit die Angabe, daß global allokierter Speicher 
unter der Umschaltlinie allokiert wird, wodurch er für die 
Anwendungen immer verfügbar ist. Sie erreichen dies durch 
das Flag GMEM_NOT_BANKED beim Aufruf der Funktion 
GlobalAlloc. Sie sollten dies als letzten Ausweg wählen, 
da der Speicher unter der Umschaltlinie sehr kostbar ist 
und deshalb von den wichtigsten Systemobjekten benötigt 
wird. Wenn Sie keinen ungewöhnlichen Grund haben, soll- 
ten Sie diese Art der Allokierung nicht nutzen. Ein gutes 
Beispiel für eine globale Allokierung unter der Umschalt- 
linie ist der Speicher, der von einem Drucker benötigt wird. 


Programmstruktur 


Um die Laufzeit Ihrer Anwendung mit einem kleinen EMS- 
Rahmen zu optimieren, sollten Sie die wichtigsten Seg- 
mente als PRELOAD in der Moduldefinition (.DEF) kenn- 
zeichnen und ihre Namen an den Beginn der SEGMENTS- 
Liste schreiben. Die Geschwindigkeit wird erhöht, da Win- 
dows beim Laden einer Anwendung mit dem umschaltbaren 
EMS-Speicher beginnt. Erst nachdem der umschaltbare 
EMS-Speicher gefüllt ist, verwendet Windows bei kleinen 
Rahmen Speicher unterhalb der Umschaltlinie. Die 
Geschwindigkeit erhöht sich, da die Speicherverwaltung von 
Windows keine Objekte oberhalb der Umschaltlinie ent- 
fernt. 


Gemeinsame Daten 


Die Zwischenablage (Clipboard), DDE und Bibliotheken 
sind Arten des Datenaustauschs, die in den aktuellen und 
zukünftigen Versionen von Windows arbeiten. Anders als 


beim Clipboard oder DDE, sollten Sie Speicher nicht durch 
die Übergabe globaler Speicherhandles unter den Anwen- 
dungen austauschen. Die Übergabe von Long-Zeigern auf 
Datenobjekte sollte ebenso vermieden werden. Sie können 
sich nicht sicher sein, daß die benötigten Daten eingeblen- 
det sind, wenn die darauf zugreifende Anwendung läuft. 
Anwendungen die diese Richtlinien ignorieren, werden 
unter zukünftigen Versionen von Windows 2.0 und Win- 
dows/386 nicht mehr laufen. 

Vergewissern Sie sich, daß Sie die Daten vom Clipboard 
in Ihren eigenen Datenbereich kopieren, bevor Sie das 
Clipboard schließen. Windows unterstützt EMS, indem es 
die Objekte der Zwischenablage, die ausgeblendet wurden, 
in den gerade eingeblendeten Speicher kopiert. Nach dem 
Schließen der Zwischenablage werden diese Objekte 
gelöscht, was sie für die darauf zugreifende Anwendung 
ungültig macht. 

Wenn eine Anwendung eine globale Handle von der 
Zwischenablage oder dem DDE erhält, muß es den Ergeb- 
niswert der Funktion GlobalXAX1lockprüfen. Die Windows- 
Speicherverwaltung kopiert in die aktuelle Seite diejenigen 
Zwischenablage- oder DDE-Objekte, die im ausgeblende- 
ten EMS-Speicher liegen. Ist die Speicherverwaltung nicht 
in der Lage den Kopiervorgang durchzuführen (wenn zum 
Beispiel der Speicher zu knapp wird), informiert sie die 
Anwendung durch die Rückgabe von NULL beim Aufruf 
von Globallllock. 


Gemeinsamer Programmbereich 


Eine Neuerung von Windows ist die Möglichkeit, Pro- 
grammteile gemeinsam zu benutzen. Nur eine Kopie einer 
Windows-Funktion ist zu einer Zeit im Speicher. Sie kann 
durch einen dynamischen Linkmechanismus von allen 
Anwendungen aufgerufen werden. Wenn sie saubere Win- 
dows-Anwendungen programmieren, wird der gemeinsame 
Zugriff auf Programmteile durch den EMS-Speicher nicht 
beeinträchtigt. Da mehrere Vorkommen der gleichen 
Anwendung in denselben Seiten des EMS laufen, gibt es 
kein Problem mit dem gemeinsamen Zugriff auf Programm, 
Daten oder Ressourcen. 

Dynamische Linkbibliotheken sind eine Möglichkeit zur 
gemeinsamen Verwendung von Programmteilen durch 
mehrere Anwendungen. Windows lädt die entfernbaren 
Bibliothekssegmente oberhalb der Umschaltlinie, so daß 
mehrere Kopien desselben Codesegments im EMS-Spei- 
cher vorkommen können. Diese Redundanz kann durch 
Konvertieren dieser Bibliothek in eine fensterlose Task und 
durch die Kommunikation mit den Message-Routinen 
PostMessage und PostAppMessage vermieden werden. 

Sie können keine Programmteile, die zu einer anderen 
Task gehören, direkt aufrufen. Sie können also nie Get- 
ProcAdress aufrufen, um Programmteile einer anderen 
Task selbst aufrufen zu können. Obwohl dies in der Version 
1.x funktionierte, läßt es die Speicherverwaltung von Win- 
dows 2.0 nicht zu. Statt dessen können Sie die Funktion 
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Windows 


SendMessage für die Kommunikation zwischen verschie- 
denen Tasks benutzen. 

Eine Anwendung kann den EMM direkt aufrufen, um 
EMS-Speicher zu allokieren, vorausgesetzt sie befolgt die 
Richtlinien der Version 3.2. Sie kann auch die Wiederallo- 
kierfunktion (ReAlloc: Funktion 17) von LIM EMS 4.0 
verwenden. Windows muß dies mitgeteilt werden, so daß es 
nicht den 64 Kbyte großen Rahmen von EMS 3.2 verwen- 
det. Dies geschieht durch die Angabe von -LIM32 beim 
Aufruf des Ressourcen-Compilers. Windows vermeidet das 
Einblenden von Programmteilen in den 64 Kbyte großen 
EMS-3.2-Rahmen für Ihre Anwendung, es kann diesen 
Rahmen aber weiterhin für andere Anwendungen verwen- 
den. 


Globaler Speicher 


Sie sollten keinen globalen Speicher unterhalb der 
Umschaltlinie allokieren. Sie sollten also das Flag 
GMEM_NOT_BANKED beim Aufruf von GlobalAlloc ver- 
meiden. Wenn globale Objekte zwischen Anwendungen 
ausgetauscht werden, so sorgt der Aufruf von GlobalLock 
für das Kopieren der benötigten Blöcke. Dies sollte aber 
nur mit den Methoden der Zwischenablage und des DDE 
genutzt werden, um Kompatibilität mit neueren Versionen 
von Windows 2.0 und Windows/386 zu gewährleisten. 

Ihr Programm sollte immer Fehler beim Allokieren, 
Wiederallokieren und beim Sperren von Speicher prüfen. 
Dies ist kritisch bei der Verwendung von DDE oder dem 
gemeinsamen Datenbereich der Zwischenablage, und es 
stellt eine gute Windows-Programmierpraxis dar. Ein 
ungültiger Far-Zeiger kann tödlich sein, da Daten irgendwo 
im Speicher geschrieben oder gelesen werden können. 


Windows-Hooks 


Die Windows-Anknüpfungspunkte (Hooks) erlauben Ihnen 
das Abfangen einiger Ereignisse vor dem Einfügen in die 
Systemschlange. Sie können zum Beispiel eine Tastatur- 
überwachung programmieren, die die Taste [Alt)[P) über- 
wacht. So kann ein Hintergrundprogramm einen Ausdruck 
des Bildschirms auf dem aktuellen Drucker durchführen. 

Die Auswirkung des EMS-Speichers auf die Windows- 
Anknüpfungspunkte erfordert ein wenig zusätzlichen Pro- 
grammieraufwand. Die Windows-Anknüpfungspunkte müs- 
sen unterhalb der Umschaltlinie in festen Bibliotheksseg- 
menten liegen. Da der Windows-Anknüpfungspunkt nie 
weiß, ob die Task gerade eingeblendet ist, muß er mit der 
aufrufenden Task über eine Nachricht kommunizieren (zum 
Beispiel SendMessage). 

Debugger-Unterstützung 

Sie können jetzt zum Fehlersuchen in einer Windows-2.0- 
Anwendung CodeView benutzen. Das stellt eine wesent- 
liche Verbesserung gegenüber Symdeb - einem mächtigen, 


aber kryptischen Debugger - dar, der am besten für Assem- 
bler-Programmierer geeignet ist. CodeView verlangt ent- 
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weder einen monochromen Monitor oder ein Terminal, da 
Windows die Kontrolle über den Bildschirm übernimmt. 
Eine weitere Voraussetzung ist das Vorhandensein von 
EMS-Speicher, da Code View direkt die Expanded Memory- 
Speicherverwaltung anspricht, um den Speicher, der der 
Anwendung fehlt, möglichst gering zu halten. 

Um das Debuggen zu erleichtern, wenn EMS vorhanden 
ist, sollten Sie die folgenden Zeilen in die Datei WIN.INI 
schreiben: 

[kernel] 
EnableEMSDebug=1 

Dies erlaubt Ihnen das Setzen von Breakpunkten in 
entfernbaren Bibliotheksfunktionen. Erinnern Sie sich, daß 
es mehrere Kopien von diesen entfernbaren Bibliotheks- 
funktionen in verschiedenen EMS-Seiten geben kann. Der 
Schalter teilt der Speicherverwaltung mit, daß die Tabelle 
der entfernbaren Bibliotheksfunktionen bei der Kontext- 
umschaltung des Debuggers aktualisiert werden muß. Jeder 
Debugger, der mit Windows zusammenarbeitet wie Sym- 
deb, CodeView, Answer oder Atron arbeitet auch richtig 
mit EMS. 


Zusammenfassung 


In den meisten Fällen ist die Expanded Memory-Speicher- 
unterstützung von Windows für den Programmierer trans- 
parent. Mit der Ausnahme einer neuen Windows-Biblio- 
theksfunktion, LimitEMSPages, einigen neuen Flags und 
einer neuen Option des Ressourcen-Compilers, hat sich die 
Schnittstelle, die Windows-Programmierer verwenden, nicht 
geändert. Was sich aber geändert hat, ist die strengere 
Trennung zwischen den Tasks. Der Zugriff auf gemeinsame 
Daten muß nach einer der drei Arten erfolgen: Zwischen- 
ablage, DDE oder über gemeinsame dynamische Link- 
bibliotheken. Der ohnehin problematische direkte Zugriff 
auf Funktionen einer anderen Task, ist unter der Speicher- 
verwaltung von Windows 2.0 unmöglich. 

Programmierer haben den größten Vorteil vom 
Geschwindikeitszuwachs unter Windows 2.0, wenn Sie viele 
große Anwendungen laufen lassen. Dies läßt Produkte, die 
mit Anwendungen wie Microsoft Excel oder PageMaker 
zusammenarbeiten, attraktiver erscheinen. Windows-Ent- 
wickler können natürlich auch Ihre eigenen leistungsfähigen 
und großen Anwendungen programmieren. Da die EMS- 
Unterstützung für den Programmierer transparent ist, kann 
er die bestehende Programmschnittstelle verwenden, und 
die Windows-Speicherverwaltung die Vorteile von EMS 
nutzen lassen. 

Paul Yao 


Fachbegriffe der Windows- 
Speicherspeicherverwaltung 


Umschaltlinie (bank line): Auch Grenze der EMS-Auslage- 
rung genannt. Dies ist die Grenze, unter der der Speicher 
nicht umgeschaltet wird, und über der er umgeschaltet wird. 
Wenn Windows mit Expanded Memory arbeitet, ist der 
nicht umgeschaltete Speicher immer verfügbar, der umge- 
schaltete aber nur, wenn die Task läuft, der dieser Speicher 
gehört. 

Umgeschalteter Speicher (banked memory): Speicher, der 
innerhalb des physischen Adreßbereichs des 8088 liegt 
(eingeblendet ist), wohin er von einem Treiber (Expanded 
Memory Manager) in Verbindung mit einer Expanded 
Memory-Karte gelegt wird. 

Kontextumschaltung: Die Änderungen, die Windows 
durchführen muß, wenn der Anwender von einer Applika- 
tion zu einer anderen wechselt. Es wird zum Beispiel 
sowohl Windows Write als auch Windows Paint geöffnet. 
Wenn der Anwender Text in Windows Write eingegeben 
hat, und die Maus in Windows Paint anklickt, vollzieht das 
System eine Kontextumschaltung. Die einzige Auswirkung 
für den Anwender ist die Farbänderung in der Menüleiste. 
Wurde das jetzt aktive Fenster von einer anderen Anwen- 
dung verdeckt, holt Windows 2.0 es an die Oberfläche. 
Entfernbare Speicherobjekte (Discardable memory object): 
Eines der Flags, die die Speicherverwaltung setzt, um die 
verschiedenen Arten von Speicherobjekten beim Allokieren 
von Speicher zu kennzeichnen. Kann die Windows-Spei- 
cherverwaltung eine Allokierung durch einfaches Verschie- 
ben von Speicherobjekten nicht erfüllen, so gibt sie entfern- 
bare Speicherobjekte nach einem »least recently used«- 
Verfahren frei. 

Dynamisch allokierter Speicher: Der Speicher, den ein 
Windows-Programm direkt von der Windows-Speicherver- 
waltung anfordert. In diesem Artikel ist dies gleichbedeu- 
tend mit global allokiertem Speicher. 

Enhanced Expanded Memory Specification (EEMS): Eine 
Erweiterung der Expanded Memory-Spezifikation, die es 
gestattet, jeden Teil des Adreßbereichs des 8088 ein- und 
auszublenden. 

Expanded Memory Specification (EMS): Diese Spezifika- 
tion, die auch unter dem Namen LIM EMS bekannt ist, 
definiert, wie ein Programm Expanded Memory allokieren 
und benutzen muß. Dies beruht auf Aufrufen des Expanded 
Memory-Einheitentreibers. 

Expanded Memory Manager (EMM): Ein Einheitentreiber 
(device driver), der Expanded Memory kontrolliert. EMS 
definiert, wie ein Programm mit dem EMM kommuniziert, 
um Expanded Memory zu allokieren, einzublenden, und 
wieder freizugeben. 


Extended Memory: Der Speicher über 1 Mbyte bei einem 
80286- oder 80386-Computer. Diese Art von Speicher kann 
nur im Protected Modus direkt adressiert werden, so wie 
OS/2 dies tut. Normalerweise wird Extended Memory für 
RAM-Disks oder Druckerspooler benutzt. Viele Speicher- 
karten können für Expanded, Extended oder gemischte 
Adressierung eingestellt werden. 

Handle: Ein Wert, der beim Erzeugen eines Objekts 
zurückgegeben wird. Handles identifizieren von Windows 
dynamisch allokierte Speicherobjekte. 

Logische Seite: Ein Segment des Expanded Memory. EMS- 
Speicher wird in logischen Seiten allokiert, die gewöhnlich 
16 Kbyte groß sind. Um auf Daten in diesen logischen Sei- 
ten zugreifen zu können, muß EMS die logischen Seiten in 
den physischen Rahmen einblenden. 

Einblenden: Die Art, wie eine logische Seite des Expanded 
Memory in den Adreßbereich des 8088 gelegt wird, um sie 
vom Programm aus ansprechen zu können. 

Unterstützung alter Applikationen: Die Fähigkeit von 
Windows, zeichenorientierte Standard-MS-DOS-Applika- 
tionen, wie Microsoft Word, Lotus 1-2-3 oder Microrim 
R:BASE System V auszuführen. 

Seitenrahmen (page frame): Eine Ansammlung physischer 
Seiten, in die die logischen Seiten eingeblendet werden 
können. 

Physische Seiten: Der absolute Adreßbereich im 1 Mbyte- 
Adreßraum des 8088, in den die logischen EMS-Seiten ein- 
geblendet werden. 

Thunk: Ein kleines Programmstück, das an einer festen 
Stelle im Speicher sitzt, um Aufrufe einer Funktion in 
einem verschiebbaren oder entfernbaren Segment abzufan- 
gen. Thunks sind ein wichtiger Teil der dynamischen Link- 
bibliotheken von Windows. Dies erlaubt der Speicherver- 
waltung von Windows das Verschieben oder Entfernen von 
Segmenten mit geringem Aufwand. Weitere Aufrufe ver- 
anlassen, das Segment mit der benötigten Routine nach- 
zuladen. Return-Thunks werden erzeugt, um die Rückkehr 
zu einem entfernten Programmteil abzufangen. Thunks füh- 
ren auch Kontextumschaltungen durch. Das der von Make- 
ProcInstance erzeugte Thunk, um sicherzustellen, daß 
eine Dialogbox das richtige Datensegment benutzt. 

Fenster: Ein anderes Wort für den Seitenrahmen von EMS. 
Speicherverwaltung von Windows: Der Teil von Windows, 
der Programm- und Datensegmente in den Speicher lädt. 
Die Speicherverwaltung von Windows versucht, Anforde- 
rungen von dynamischem Speicher zuerst durch das Ver- 
schieben von Objekten zu erfüllen. Funktioniert dies nicht, 
dann entfernt sie Objekte, die als entfernbar gekennzeich- 
net sind. Die Speicherverwaltung von Windows 2.0 wurde 
um die Fähigkeit der Speicherumschaltung zwischen Win- 
dows-Anwendungen erweitert. 
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Buchbesprechungen 


D m versucht seine Bücherfl 


bewälti 


n (Teil II): 


Einige Kurzbesprechungen 


Es sind in den letzten Wochen wieder so viele interessante 
Bücher in der Redaktion eingetroffen, daß es einfach nicht 
mehr möglich ist, sie alle zu lesen, geschweige denn aus- 
führlich zu besprechen. Etliche sollen jedoch zumindest mit 
kurzer Inhaltsangabe und bibliographischen Informationen 
vorgestellt werden. 


08/2 


Wer vor englischsprachiger Fachliteratur nicht zurück- 
schreckt findet in David E. Cortesis Buch »Essential OS/2« 
auf 450 Seiten viele nützliche Informationen und Beispiele 
für die Programmierung unter OS/2 1.0. Auf zusätzlichen 
230 Seiten werden detailliert alle Funktionen der Program- 
mierschnittstelle beschrieben. 


David E. Cortesi: »The Programmer’s Essential OS/2 Hand- 
book: Redwood City: M&T Publishing 1988; 709 Seiten; 
ISBN 0-934375-82-8; 324.95. 3 Disketten 825. 


Windows 


In der letzten Ausgabe haben wir das erste deutsche Win- 
dows-Buch vorgestellt, doch dabei ist es nicht geblieben. 
Der Systhema Verlag bringt mit »Programmierung unter 
Windows« eine Einführung in die Windows-Programmie- 
rung für Windows-interessierte Umsteiger. Der Autor Tim 
Farrell schöpft aus seinen Erfahrungen bei der Entwicklung 
mehrerer kommerzieller Windows-Anwendungen und 
demonstriert am Beispiel eines einfachen Programmeditors 
Schritt für Schritt die für viele Programmierer neuen 
Aspekte der meldungsgesteuerten Programmierung unter 
Windows. 


Tim Farrell: »Programmierung unter Windows«, München: 
Systhema Verlag, 1989; 500 Seiten; inklusive 2 Disketten; 
ISBN 3-89390-251-1; DM 98,-. 


Programmiersprachen 


Während C im professionellen Bereich ganz klar die favori- 
sierte Programmiersprache ist, gebührt BASIC dieser Platz 
im Amateurlager und semiprofessionellen Bereich. 

Für C bietet der Verlag McGraw-Hill die »C-Befehls- 
bibliothek«, ein umfassendes Nachschlagewerk zur Sprache 
C, an. Der bekannte C-Autor Herbert Schildt legt hiermit 
einen ausführlichen Überblick über die Sprache C und ihre 
Laufzeitbibliothek vor. Dabei wird auch die neueste Ent- 
wicklung (ANSI-Norm, C+ +) berücksichtigt. 

Herbert Schildt: »C-Befehlsbibliothek«, Hamburg: McGraw- 
Hill, 1988; 752 Seiten; ISBN 3-89028-142-7. 


H. Herold und W. Unger gaben ihrem Werk über C den 
Titel »C-Gesamtwerk«, wodurch man zunächst glaubt, daß 
es sich um ein ähnliches Nachschlagewerk, wie das Buch 
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von H. Schildt handelt. Doch die Struktur diese Buchs ist 
ganz anders. Hier wird an über 100 kommentierten kleinen 
Programmbeispielen die Realisierung moderner Pro- 
grammstrategien in C vorgeführt. Berücksichtigt werden 
dabei C-Compiler unter allen bekannten Betriebssystemen, 
von CP/M über DOS bis zu Unix. 


Helmut Herold, Werner Unger: »C-Gesamtwerk«, München: 
te-wi Verlag, 1988; 570 Seiten; ISBN 3-89362-015-X; DM 79,-. 


Um die Umsetzung eines Problems in ein lauffähiges 
BASIC-Programm geht es in H.-J. Sachts Einführung in das 
Programmieren mit BASIC. Dieses 1983 zum ersten Mal 
erschienene Werk wurde für die vorliegende 4. Auflage 
stark überarbeitet und erweitert. Es eignet sich vor allem 
für Programmiereinsteiger. 


Hans-Joachim Sacht: »Vom Problem zum Programm//Pro- 
grammieren in GW-BASIC, Turbo BASIC und Quick- 
BASIC« Würzburg: Vogel Verlag, 4. Aufl. 1988; 462 Seiten; 
ISBN 3-8023-0214-1; DM 48,-. 


Wesentlich weiter führt »Das große PC-BASIC-Buch« von 
Heinz-Josef Bomanns. Hier werden in ausführlichen Bei- 
spielen praxisorientierte Themen wie Grafik, Sound, Datei- 
verwaltung, Bildschirmansteuerung, Druck usw. beschrie- 
ben. Auch die BASIC/Assembler-Kopplung kommt nicht 
zu kurz. Auf kompaktem Raum hat Bomanns sein Know- 
How zu QuickBASIC in einem Data Becker Führer zusam- 
mengefaßt. Es werden dabei alle Versionen von 2.0 bis 4.0 
berücksichtigt. 


Heinz-Josef Bomanns: »Das große PC-BASIC-Buch (GW- 
BASIC/QuickBASIC«, Düsseldorf: Data Becker, 1988; 734 
Seiten; mit einer Diskette; ISBN 3-89011-240-4; DM 69,-. 


Heinz-Josef Bomanns: »Der DATA BECKER Führer Quick- 
BASIC«, Düsseldorf: Data Becker, 1988; 250 Seiten; ISBN 3- 
89011-451-2; DM 24,80. 


Auch FORTRAN, der Oldtimer unter den Programmier- 
sprachen, wird (vor allem bei rechenintensiven Anwendun- 
gen) noch immer eingesetzt. Das Buch beschreibt, wie man 
mit Microsoft FORTRAN 4.0 zeitgemäß strukturiert pro- 
grammiert. 


Hans Mahnke: »Strukturiert programmieren in Fortran 77«, 
Würzburg: Vogel Verlag, 1988; 126 Seiten; ISBN 3-8023-0221- 
4 DM 30,-. 


Wer keine umfangreichen Beispiele für die Programmie- 
rung unter DOS benötigt und mit einer kurzen Auflistung 
der Programmierschnittstelle auskommt, dem sei folgendes 
kleine Büchlein empfohlen: 


Ray Duncan: »MS-DOS Functions«, Redmond: Microsoft 
Press, 1988; 122 Seiten; ISBN 1-55615-128-4; 85.95. 


»Profi-Tools QuickC«: 


Stringbehandlung in C 


In dem Buch »Profi-Tools QuickC« wird dem 
Leser eine Library mit etwa 60 Funktionen zur 
Verfügung gestellt, die ihm das Leben erleich- 
tern sollen. Diese Library ist sowohl für die 
Benutzung mit dem QuickC- als auch mit dem 
C-5.0-Compiler geeignet. Wir bringen hier als 
Buchauszug daraus das Modul MYSTRING mit 
Routinen zur Stringbehandlung. 


MYSTRING enthält in der Praxis häufig benötigte String- 
funktionen, die nicht in der QuickC-/C 5.0-Library enthal- 
ten sind. Zum Beispiel Funktionen zum Löschen oder Ein- 
fügen eines Strings, Funktionen zum Durchsuchen eines 
Strings nach dem nächsten beziehungsweise vorhergehen- 
den Wort, oder Funktionen, mit denen es möglich ist, ohne 
wiederholten Aufruf von concat einen String aus mehre- 
ren Teilstrings zu bilden. MYSTRING enthält also Funktio- 
nen, die den Umgang mit Strings erheblich vereinfachen. 


charins: ein Zeichen in einen String einfügen 
strins: einen String in einen zweiten String einfügen 
strdel: einen Teil eines Strings entfernen 

strfill: String teilweise mit einem Zeichen füllen 
strstring: einen String mit einem Zeichen füllen 
strpad: einen String mit Leerzeichen auffüllen 
strcompress: »überflüssige« Leerzeichen löschen 
lower: Groß- in Kleinbuchstaben wandeln 

upper: Klein- in Großbuchstaben wandeln 

instr: das Enthaltensein eines Strings prüfen 
nextword: das nächste Wort suchen 

prevword: das vorhergehende Wort suchen 

stradd: einen String aus mehreren Teilstrings bilden 
charadd: einen String aus mehreren Zeichen bilden 


Wenn Sie einen Blick in die Dokumentation Ihres Com- 
pilers werfen, kommen Ihnen lower und upper auf den 
ersten Blick wahrscheinlich überflüssig vor. Im Gegensatz 
zu den dort beschriebenen Makros berücksichtigen diese 
beiden Funktionen jedoch auch Umlaute korrekt. 

Beachten Sie bitte bei allen Funktionen, die die Länge 
des Ausgangs-Strings verändern, daß für den String ausrei- 
chend Platz reserviert sein muß (charins, strins, 
strstring, strpad, stradd, charadd). Keine der 
Stringfunktionen allokiert Speicherplatz für den String; er 
wird in allen Fällen als bereits reserviert vorausgesetzt! 


charins: 
Zeichen in String einfügen 


Syntax: void charins(char ch, char *s) 
Eingabeparameter: ch: einzufügendes Zeichen, s: Pointer 
auf Einfügeposition im String 

Funktionswert: keiner 

Funktion: charins fügt ein Zeichen in einen String ein 
und verschiebt alle nachfolgenden Zeichen um eine Position 


(und das abschließende ’\9'). Die Länge des resultieren- 
den Strings iststrlen(s) + 1. 
Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h 


main() 


{ 
char s[81]; 


strcpy(s, "Des ist ein Test"); 
charins(’i’, &s[1]); 
printf("Ie", s); 


=> Dies ist ein Test 


strins: 
Einen String in einen zweiten einfügen 


Syntax: void strins(char *si, char *s2) 
Eingabeparameter: si: Pointer auf den einzufügenden 
String, s2: Pointer auf die Einfügeposition 

Funktionswert: keiner 

Funktion: strins fügt einen String si in einen zweiten 
String s2 ein; alle Zeichen, die der Einfügeposition folgen 
(inklusive ’ \9’), werden verschoben. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main( ) 
{ 
char s[81]; 


strepy(s, "Dies ein Test"); 
strins(" ist", &s[4]); 
printf("%s", s); 


=> Dies ist ein Test 


strdel: 
Teil eines Strings entfernen 


Syntax: void strdel(char *start, char *ende) 
Eingabeparameter: start: Pointer auf das erste zu entfer- 
nende Zeichen, ende: Pointer auf das letzte zu entfernende 
Zeichen 
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Funktionswert: keiner 

Funktion: strdel entfernt alle Zeichen eines Strings von 
start bis ende; alle ende folgenden Zeichen (inklusive 
’\0’) werden nach start ff. verschoben. 

Beispiel: 


#include <<stdio.h>> 
#include "myheader.h" 


strfill: String teilweise mit einem Zeichen füllen 


Syntax: void strfill(char *start, char *ende, 
char ch) 

Eingabeparameter: start: Pointer auf das erste zu über- 
schreibende Zeichen, ende: Pointer auf das letzte zu über- 
schreibende Zeichen, ch: Zeichen, mit dem überschrieben 
wird 

Funktionswert: keiner 


#include "myinit.h" @ 5 . . a 
ade Funktion: strfill überschreibt alle Zeichen eines Strings 
' von start bis ende mit dem Zeichen ch. 
main() 7 
f Beispiel: 


char s[81]; #include <<stdio.h>> 


#include "myheader.h" 


strcpy(s, "Dies ist ist ein Test"); #include "myinit.h" 
strdel(&s[4], &s[7]); ER 
printf("%s", s); { 
} char s[81]; 
strcpy(s, "Seriennummer ‚2.5.88"); 


=> Dies ist ein Test 


strfill(&s[13], &s[18], ’X’); 
printf("%s", s); 

} 

=> Seriennummer XXXXXX, 2.5.88 


Profi-Tools 


für fortgeschrittene Programmierer 


S. Baloui Profi-Tools QuickC 
1988, 209 Seiten, inkl. Diskette 
Rund 60 Funktionen, die jeder 
QuickC-Programmierer, der 
professionelle Ansprüche an 
sein Programm stellt, haben 
sollte: Bildschirmausschnitte in 
Variable kopieren, Errorhand- 
ling, komfortable Dateneingabe 
und vieles mehr 

Bestell-Nr. 90692 

ISBN 3-89090-692-3 

DM 98,-* sFr 90,20*/6S 834,-* 


In der Reihe der »Profi-Tools« finden Sie zahl- 
reiche Routinen, die jeder fortgeschrittene 
Programmierer, der professionelle Ansprüche an 
seine Programme stellt, haben sollte. Alle Rou- 
tinen sind auf der beigefügten Diskette enthalten. 


“ 
Markt& Technik Verlag AG, Buchverlag, Hans-Pinsel-Straße 2, 8013 Haar bei München, Telefon (089) 4613-0. Markt Technik 


Bestellungen im Ausland bitte an: SCHWEIZ: Markt&Technik Vertriebs AG, Kollerstrasse 3, CH-6300 Zug, Telefon (042) 415656, 
ÖSTERREICH: Markt &Technik Verlag Gesellschaft m.b.H., Große Neugasse 28, A-1040 Wien, Telefon (0222) 587 1393-0, 
Rudolf Lechner &Sohn, Heizwerkstraße 10, A-1232 Wien, Telefon (0222) 677526, 

Ueberreuter Media Verlagsges.mbH (Großhandel), Laudongasse 29, A-1082 Wien, Telefon (0222) 48 1543-0. 
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strstring: Einheitlichen String bilden 
Syntax: char *strstring(char *s, int 
len) 
Eingabeparameter: s: Pointer auf den String, ch: Zeichen, 
aus dem der String bestehen soll, len: gewünschte 
Stringlänge 
Funktionswert: Pointer auf den String 


char ch, 


strpad: String mit Leerzeichen auffüllen 


Syntax: char *strpad(char *s, int len) 
Eingabeparameter: s: Pointer auf den String, 
gewünschte Stringlänge 

Funktionswert: Pointer auf den String 

Funktion: strpad hängt an das Ende eines gegebenen 
Strings Leerzeichen an, um ihn auf eine Sollänge aufzufül- 


len: 


Funktion: strstring erzeugt einen mit '\®’ abgeschlos- 
senen String s der Länge len, der mit dem Zeichen ch 
gefüllt ist. 

Beispiel: 


len. Der String wird mit ’ \®’ abgeschlossen. 
Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include <stdio.h> #include "myinit.h" 


#include "myheader.h" 


#include "myinit.h" nn 
main() char s[81]; 
{ 
char s[81]; strepy(s, "Test"); 
strpad(s, 10); 
strstring(s, x, 18); strcat(s, "Testi"); 
printf("%s", s); printf("%s", s); 
’ ’ ) 
} 


=> Test Test 


=> XXXXXXXXXX 
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PROFI-TOOLS 
Turbo BASIC 


PROFI-TOOLS 
QuickBASIC 40 


Ren. 


Lit TIERTE 


S.Baloui Profi-Tools Turbo C S. Heinecke Profi-Tools S.Baloui S. Baloui Profi-Tools S.Balou 


1988, 208 Seiten, inkl, Diskette 
Rund 60 Funktionen für den pro- 
tessionellen Turbo-C-Program- 
mierer: Modul MYSTRING ent- 
hält häufigbenötigte Stringfunk- 
tionen. Modul MYSTDLIB ent- 
hält Assembler-Routinen zur 
schnellen Stringausgabe, Bild- 
schirmausschnitte in Variable 
kopieren, Errorhandling, kom- 
fortable Dateneingabe und vie- 
les mehr 

Bestell-Nr. 90691 

ISBN 3-89090-691-5 

DM 98,-* sFr 90,20°/6S 834,-* 


Turbo-Pascal 3.0/4.0 

1988, 211 Seiten, inkl. Diskette 
Die Toolbox enthält Routinen zur 
komfortablen Ein- und Ausgabe 
zur Mengenrechnung, zu sta- 
tistischen Anwendungen, zur 
Rechnung mit komplexen 
Zahlen, zur Matrizenrechnung 
zur Steuerung der Schnitt- 
stellen sowie vollständige An- 
wendungen aus den Bereichen 
Mathematik und Statistik 
Bestell-Nr. 90665 

ISBN 3-89090-665-6 

DM 98,-* sFr 90,20"/6S 834,-* 


Profi-Tools QuickBasic 4.0 
1988, 152 Seiten, inkl. Diskette 
Die »Profi-Tools« beinhalten 
35 Routinen, unter anderem 
zu: Bildschirmsteuerung und 
schnelle Stringausgabe in 
Assembler, Pull-down-Menüs 
einfach verwalten, überlappen- 
des Windowing, Scrollen in Win- 
dows, Verwaltung ständig sor- 
tierter _String-/Integer-Arrays 
und vieles mehr 

Bestell-Nr. 90655 

ISBN 3-89090-655-9 

DM 98,-* sFr 90,20°/6S 834.-" 


QuickBasic/PC Version 2.0/3.0 
1988, 139 Seiten, inkl. Diskette 
Die Profi-Tools beinhalten 35 
Assembler- und Basicroutinen 
die jeder professionelle Quick- 
Basic-Programmierer haben 
muß! 

Leistungsfähigkeit, Schnellig- 
keit, optimale optische Gestal- 
tung und einfache Handhabung, 
sind Schlagworte, die bei der 
Entwicklung der Tools im Vor- 
dergrund standen 

Bestell-Nr. 90615 

ISBN 3-89090-615-X 

DM 98,-* sFr 90,20°JöS 834,-* 


Profi-Tools Turbo Basic 
1988, 141 Seiten, inkl. Diskette 


Die »Profi-Tools« beinhalten 
35 Routinen, unter anderem 
zu: Bildschirmsteuerung und 
schnelle Stringausgabe in 
Assembler, Pull-down-Menüs 
einfach verwalten, überlappen- 
des Windowing, Scrollen in Win- 
dows, Verwaltung ständig sor- 
tierter  String-/Integer-Arrays 
und vieles mehr. 

Bestell-Nr. 90633 

ISBN 3-89090-633-8 

DM 98,-* sFr 90,.20°/65 834,-" 


* Unverbindliche Preisempfehlung 


Markt &Technik-Produkte / 7 SA “ 

erhalten Sie in den Fachabteilungen 2} 
der Warenhäuser, im Versandhandel, 
in Computer-Fachgeschäften oder N 
bei Ihrem Buchhändler — 


Fragen Sie Ihren Fachhändler 
nach unserem kostenlosen Gesamtverzeichnis 
mit über 500 aktuellen Computerbüchern 
/ und Software. Oder fordern Sie es direkt 
‘ beim Verlag an! 


streompress: 
Abschließende Leerzeichen entfernen 


Syntax: char *strcompress(char *s) 
Eingabeparameter: s: Pointer auf den String 
Funktionswert: Pointer auf den String 

Funktion: strcompress ist die Umkehrung von strpad; 
alle »überflüssigen« Leerzeichen am Ende eines Strings 
werden entfernt. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 


{ 
char s[81]; 


strepy(s, "Test nr 
strcompress(s); 
strcat(s, "ende"); 
printf("%s", s); 

} 


=) Testende 


lower: 
Großbuchstaben eines Strings in 
Kleinbuchstaben wandeln 


Syntax: char *lower(char *s) 

Eingabeparameter: s: Pointer auf den String 
Funktionswert: Pointer auf den String 

Funktion: lower wandelt alle in einem String enthaltenen 
Großbuchstaben in Kleinbuchstaben und berücksichtigt 
dabei auch Umlaute. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 


{ 
char s[81]; 
strepy(s, "Dies ist ein Test"); 


lower(s); 
printf("%s", s); 


=> dies ist ein test 
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upper: 
Kleinbuchstaben eines Strings in 
Großbuchstaben wandeln 


Syntax: char *upper(char *s) 

Eingabeparameter: s: Pointer auf den String 
Funktionswert: Pointer auf den String 

Funktion: upper wandelt alle in einem String enthaltenen 
Kleinbuchstaben in Großbuchstaben und berücksichtigt 
dabei auch Umlaute. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 


{ 
char s[81]; 


strepy(s, "Dies ist ein Test"); 
upper(s); 
printf("%s", s); 


=> DIES IST EIN TEST 


instr: 
Enthaltensein eines Strings prüfen 


Syntax: char *instr(char *si, char *s2) 
Eingabeparameter: s1: Pointer auf zu suchenden Teilstring, 
s2: Pointer auf den zu durchsuchenden String 
Funktionswert: Pointer auf die gefundene Position (NULL, 
wenn s1 nicht in s2 enthalten ist 

Funktion: instr prüft, ob der String si im String s2 ent- 
halten ist. Wenn ja, übergibt instr einen Pointer auf die 
gefundene Position; ist si nicht in s2 enthalten, wird NULL 
übergeben. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 


{ 
char s[81], *p; 


strepy(s, "Dies ist ein Test"); 
p = Iinstr("ist", 8); 
printf("%s", p); 

} 


=> ist ein Test 


nextword: 
Nächstes Wort suchen 


Syntax: char *nextword(char *s, char *term) 
Eingabeparameter: s: Pointer auf den String, auf die 
»Startposition«, ab der die Suche beginnt, term: Pointer 
auf einen String mit den »Terminatoren« (Zeichen, die zwei 
Wörter voneinander trennen) 

Funktionswert: Pointer auf den Anfang des nächsten Wor- 
tes (NULL, wenn kein nächstes Wort vorhanden ist) 
Funktion: nextword sucht in einem String s den Beginn 
des nächsten Wortes. Wo ein »nächstes Wort« beginnt, 
bestimmt der String term. Alle darin enthaltenen Zeichen 
werden als Trennzeichen zwischen zwei Wörtern interpre- 
tiert. Wird ein Wort gefunden, übergibt nextword einen 
Zeiger darauf, sonst NULL. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 


{ 
char s[81], *p; 


strcpy(s, "Hallo. Noch mal Hallo."); 


p = nextword(&s[2], "., !;()"); 
printf("%s", p); 


=> Noch mal Hallo. 


prevword: 
Vorhergehendes Wort suchen 
Syntax: char *prevword(char *start, char 


*ende, char *term) 

Eingabeparameter: start: Pointer auf den Stringanfang, 
bis zu dem gesucht wird ende: Pointer auf das Ende des zu 
durchsuchenden Bereichs, term: Pointer auf einen String 
mit den »Terminatoren« (Zeichen, die zwei Wörter vonein- 
ander trennen) 

Funktionswert: Pointer auf den Anfang des vorhergehenden 
Wortes (NULL, wenn kein vorhergehenden Wort vorhanden 
ist) 

Funktion: prevword ist die Umkehrung von nextword 
und erfüllt die gleiche Aufgabe, durchsucht den String 
jedoch nach links! Die Suche beginnt bei ende und endet 
bei start (start muß immer kleiner sein als ende). 
prevword übergibt einen Pointer auf den Beginn des vor- 
hergehenden Wortes beziehungsweise NULL, wenn die 
Suche erfolglos ist. 


Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 


{ 
char s[81], *p; 


strcpy(s, "Hallo. Noch mal Hallo."); 
p = prevword(s, s + strlen(s), 

N: ET 
printf("%s", p); 


=> Hallo. 
stradd: 
Strings verknüpfen 
Syntax: char *stradd(char *s, char *argl, 
., NULL) 


Eingabeparameter: s: Pointer auf den »Summenstring«, 
arg1: Pointer auf den 1.Teilstring, NULL: Endekennzeichen 
Funktionswert: Pointer auf den zusammengesetzen String 
Funktion: stradd »addiert« eine beliebige Stringanzahl. 
Die angegebenen Strings werden mit strcat verkettet und 
zu einem String s verknüpft. Dem letzten Teilstring muß 
NULL folgen. Die resultierende Stringlänge entspricht der 
Summe der Länge der Teilstrings. 

Beispiel: 


#include <stdio.h> 
#include "myheader.h" 
#include "myinit.h" 


main() 
{ 
char s[81]; 
stradd(s, "Dies ", "ist ", "ein ", 


"Test", NULL); 
printf("%s", s); 


=) Dies ist ein Test 
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charadd: 


Zeichen verknüpfen 
4a MSTRING.G 


Syntax: ner *charadd(char *s, char argl, Zuux "Standard"-Stringroutinen #*/ 
so NT 

Eingabeparameter: s: Pointer auf den »Summenstring«, |z4neiude <stdio.h> 
argi:das erste Zeichen, ' \0': Endekennzeichen #include <string.h> 
Funktionswert: Pointer auf den gebildeten String ER NUNG SShIpeN 
Funktion: charadd verknüpft beliebig viele Zeichen zu 
einem mit ’\9’ abgeschlossenen String s. Dem letzten 


Zeichen muß als Endekennzeichen ’\®' folgen. Die resul- [Die Funktionen CHARINS, STRINS und STRPAD erzeugen einen 
» Se . . String, der länger als der Ausgangsstring ist. Diese Funktionen 
tierende Stringlänge ist gleich der Anzahl der char-Argu- |gehen davon aus, daß für den zu manipulierenden String 
mente ausreichend Platz reserviert ist. Beachten Sie, daß auch 
DÜNGER STRSTRING je nach angegebener Stringlänge einen String 
Beispiel: erveitert und für STRADD ausreichend Platz für die Summe aller 
Ph ei Strings zur Verfügung stehen mup. 
%* 


[Asszzzununzznenuusssesesseessuszueuengeuuoermeneuneuusennenenen 


#include <stdio.h> /ieSSSSSuSSSnuSnESEnSoSESSSnsnssnssnnnsesosseunnnsesnunnenenene 

#include "myheader.h" 

#include "myinit.h" 
Funktion: Ein Zeichen <ch> in einen String <s> einfügen. 


main() Resultierende Länge: strlen(s) + 1. 
Hin: ch : Zeichen 
{ y s : Ptr. auf Einfügeposition im Ausgangsstring 
. % 
char s[81]; void charins(char ch, char *s) 
charadd(s, ms, let, gt, tr, ’\9'); int i; 
printf("%s", s); for (1 = strlen(s) + 1, s +#= 4 - 1; 1; i--, s--) 
) *(s + 1) = x; 
\ *(++5) = ch; 
ÜSSSSSSESSSSEESESEEEEEEESEREESEENEESESSEERZENRENEEESZBREEGEIEnEn 
=) Test L 
Said Baloui 
Funktion: String <s1> in String <s2> einfügen. 
Resultierende Länge: strlen(s1) + strlen(s2). 
Hin: si : Ptr. auf einzufügenden SR 
y s2 : Ptr. auf Einfügeposition im Ausgangsstring 
* 
Dieser Artikel ist ein Auszug aus dem Buch »Profi-Tools Pr strins(char *s1, char *s2) 
QuickC« von Said Baloui, erschienen im Markt&Technik int i, len; 
Von a e i a 
erlag, mit dessen freundlicher Genehmigung der Abdruck For VHS Fear 
erfolgt. 1; 1--, s2--) 


*(s2 + len) = %s2; 
s2++; 


for ( ; *s1; si++, s2+) 
' “52 = *sl; 


[AeSSsSusnneonneneneemesnsnnESEoemeeeEIESEeETeeemen een en nennen 


/* STRING-Funktionen (MYSTRING.C) */ 
(char ch, char *%s); 
(char *s1, char *s2); 
(char *start, char *ende); 
void strf?!1ll (char *start, char *ende, char ch); 
char *strstring (char *s, char ch, int len); 
char‘ *strpad (char *s, int len); 


Funktion: Entfernt aus einem String alle Zeichen von <start> 
bis <ende> durch Links-Verschieben der nachfolgenden 
Zeichen (inkl.’\8’). 

Hin: start : Ptr. auf das erste zu löschende Zeichen 
ende : Ptr. auf das letzte zu löschende Zeichen 


“/ 
ae strdel(char *start, char *ende) 


char *strcompress (char *s); 

char *]lower (char *%s); 

char *upper (char *s); 

char *instr (char *s1, char *%s2); 

char *nextword (char *s, char *tern); 

char *prevword (char *start, char *ende, char *tern); 
char *stradd (char *%, ...); 

char *charadd (char *, ...); 


endet+; 
while (*start++ = *ende++) 


} 


[eessmuununmeunneesunsnnennnenunnensununnsennnenuumnunnnnenneen 


Listing 1: MYHEADER..H. Listing 2: MYSTRING.C. 
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Funktion: Überschreibt in einem String alle Zeichen ab <start> 
bis <ende> mit dem Zeichen {ch> 
Hin: start i Ptr. auf das erste zu überschreibende Zeichen 
ende : Ptr. auf das letzte zu überschreibende 
Zeichen 
: "Füllzeichen” 


“/ 
Fass strfill(char *start, char *ende, char ch) 
int i; 


for (i = ende - start + 1; 1; i--) 
*ende-- = ch; 


[HesemunnunnsunsnunnununnnnnnunnnunmEnmuumEnenEmuNEnnEnmnnunnen 


strstring 


Funktion: eg 3 einen - mit ’\8" abgeschlossenen - String 
ol e <len>, gefüllt nit dem Zeichen <ch> 
Hin: Ptr. auf String 
Ten : Soliänge des Strings 
RETURN : Ptr. auf erzeugten String 


“/ 
Pa *strstring(char *s, char ch, int len) 


int 1; 
char *p; 


P*=5; 

for (1 = 8; i < len; i+) 
AS++ = ch; 

“= '\g’; 

return (p); 


[Hesenununenesmunnnnnneenenmunnmeonnnenmennnennuenenemneeeneeenee 


Funktion: Füllt einen String bis zur une Länge mit 
EOMEREIDIMER auf und schließt den String mit ’\8’ 


Result. „Länge: len. 
Hin: s : Ptr. auf den String 
len : Sollänge 
y RETURN : Ptr. auf den aufgefüllten String 
% 
a *strpad(char *s, int len) 


strfill(s + strlen(s), s + len - 1, ’ ’); 
*%(s + len) = '\B'; 
return (s); 


[Wessunsnseennsoonsnnnunnnennsnmuuesnuesennnnnerunuunnnenmenneee 


Funktion: U Umkehrung von STRPAD. Entfernt alle "rechtsbündigen” 
Leerzeichen. Kompriniert einen String auf seine 
Du „Länge durch entsprechendes Setzen von '\ß’. 

Hin: : Ptr. auf den String 

y RETURN : Ptr. auf den String 

% 


aa *strcompress(char *s) 
char *p; 


=5; 
: += strlen(s) =33 
while (s)=p && *==') 
3-7 
*(++5) = '\g; 
} return (p); 


[AeSsneszunzsesnnnnsenennoseuommnsnenennnunnunnunnnmnneemnmnnnn 


Listing 2: (Fortsetzung) 


Funktion: Wandelt alle Großbuchstaben eines Strings in 
on 

Hin: : Ptr. auf String 

y RETURN : Ptr. auf String 

%* 


"ag *lower(char *s) 
char %p; 


P = 5; 

while (*s) { 

’ö’; break; 
‚gr: break; 
sur: break; 


default : *s tolovwer(*s); 


s+t+; 


} 
return(p); 


[HeSESESSSSSEEESnENSEESEnUSESEERSESEEREEnEEERLEEEEEnuU—TEnnnunen 


Funktion: Wandelt alle Kleinbuchstaben eines Strings in 
Gropbuchstaben 
Hin: s » Ptr. auf String 
y RETURN : Ptr, auf String 
* 


En %*upper(char *s) 
char *p; 


8; 
Inte” (#s) { 
switch (*s) { 
case 'ö' 
case 'ä’ : 
case 'Ü’ : 
default toupper (*s); 


St+; 


return(p); 


[HsesseoununesnesusessnuussssnunnnneEnEunEEuuEEEEEEEnRnEnnEnnEnne 


instr 


Funktion: Prüft, ob der String <s1> im String <s2> enthalten 


: Ptr. auf den Vergleichsstring 

» Ptr. auf den durchsuchten String 
RETURN : Zeiger auf gefundene Position 

(NuULL=nicht enthalten) 


/ 
er *instr(char *s1, char *s2) 
char *ptri, *ptr2; 


for ( ; *s2; s2++) { 
for ( tri = si, 
*ptri && een u "ptr2) F 
pirie, ptr2++ 


ptr2 = s2; 


if (t tr1) 
Falun (52); 


return (NULL); 


[essesnsussuunsesssssessnsssnmnenmnneeeineeneeneennnuuuezenenen 


Listing 2: (Fortsetzung) 


Januar/Februar 19899 Microsoft System Journal 89 


Funktion: Sucht in einen te das nächste Wort (nach rechts) 
Hin: s : Ptr. auf String 
term : Ptr. auf String mit Trennzeichen zwischen 
Wörtern 
RETURN : Ptr. auf Wortanfang (NULL, wenn kein weiteres 
Wort) 
% 
gl *nextword(char %*s, char *tern) 
while (*%s &% (t strchr(tern, *s))) 
S+tt; 
while (*s &%& (strchr(tern, *s))) 
St+; 
return (%s ? s NULL); 


} 


[Aessuuessuunnumnenunueeenenunnnnennnmonneeenmennnenennnnennnne 


Funktion: Umkehrung von NEXTWORD. Sucht - ausgehend von der 
45) Position <ende> - das vorhergehende Wort (nach 
links). 


Die Suche endet, wenn die Position <start> erreicht 
ist (norsalerveise wird als <start> der re 
übergeben. Kriterium für "Wort-Terminatoren” ist 
wieder der Inhalt von TERM. 
start : Ptr. auf die linke Grenze 
ende : Ptr. auf die rechte Grenze 
term : Ptr. auf String mit Trennzeichen zwischen 
Wörtern 
RETURN ee Wortanfang (NULL, wenn kein letztes 
or 


*/ 
Fa *prevword(char *start, char *ende, char *term) 


while ((start <= ende) && (t strchr(tern, *ende))) 

uhtle (Istart <= ende) && (strchr(term, *ende))) 

alle Uistart <= ende) & (t strchr(tern, *ende))) 
} Fa alias ? ende + 1 NULL); 


[HesSsusuunsssnsnnsnsnsnsnnnenmnoumunomunnmeeeenenenenemenennnnen 


Funktion: Verknüpft eine variable Anzahl Strings durch 
"Konkatenieren” (wiederholter Aufruf von STRCAT) zu 
einem Gesantstring. 

Resultierende Länge: strlen(arg!) + ... + 

are JentangN) 

Hin: : Ptr. auf den "Summenstring” 

: Ptr. auf 1.Teilstring 

: Ptr. auf 2.Teilstring 


: Ptr. auf N,Teilstring 
: Endenarke 
: Ptr. auf erzeugten "Summenstring” 
j .: stradd(s,"Dies ","ist ",”"ein ”,"Test”, NULL); 
er *stradd(char *%s, ...) 
char **argp; 
argp = 8s; 
argpt+t; 
strepy(s, *ar I; 
while (*argp) 
Sul *argp); 
argp++; 
return (Ss); 


[Assa=220SunSSSEunnnunnuuEEEunEEnEIEEEne Teens nennen 


Listing 2: (Fortsetzung) 
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Funktion: Verknüpft eine variable Anzahl Zeichen zu einem mit 
’\8" abgeschlossenen Fa 
Resultierende Länge: Anzahl Zeichen 
Hin: s : Ptr. auf den "Summenstring” 
arg! : 1.Zeichen 
er : 2.Zeichen 


: N.Zeichen 
: Endemarke 


: Ptr. auf erzeugten String 
I Bsp.: charadd(s, 'T', ’e’, !s!, ’t’, '\9'); 
%* 


vr “charadd(char %s, ...) 
char *argp, *p; 


P:® las 

argp 

ee Gi += sizeof(char *%); *s = *argp; s++, argp += 2); 
return Bi‘ 


Listing 2: MYSTRING.C. 


PROFI C-TOOLS 
I! Neu Neu Neu |! 
CURSES 


DER Fenster Manager 
aus der UNIX-Welt. 
Jetzt unter MS-DOS. 


FORMATION 
DER Fenster-, Menü-, 
und Dialogboxenmanager 
unter CURSES. 

Konzentrieren Sie sich bei Ihren 
Programmen auf das Wesentliche! 
Überlassen Sie UNS die aufwendi- 
ge Verwaltung einer professionel- 
len Benutzeroberflächel 

Portieren Sie UNIX und XENIX Pro- 
gramme auf MS-DOS oder umge- 
kehrt. 

Entwickeln Sie schon heute Pro- 
gramme auf Ihrem PC für die 
UNIX-Welt von morgen! 

Für alle gängigen C-Compiler wie: 
Microsoft C, Turbo C und Lattice. 
Mit ausführlichen deutschen Hand- 
büchern! Alle Tools sind auch mit 
dokumentierten Quelltexten erhält- 
lich. 

Fordern Sie noch heute kostenlo- 
ses Informationsmaterial oder die 
Demodiskette für DM 10,— anl 


KICKSTEIN software 
Manfred Kickstein 
Isarstraße 28B 
D-8900 AUGSBURG 21 
= 08 21-81 4666 


Eingetr. Warenzeichen: 

MS-O, MS-DOS, XENIX: Microsoft; 
Turbo C: Borland; Lattice: Lattice Inc, 
UNIX: ATST 


PC Intern - das Buch der Superlative: In 
der jetzt erscheinenden Neuauflage mit 
über 900 starken Seiten(!) finden Sie 

das gesamte Know-how zum PC - sei es 
Hardware, BIOS oder DOS. Zusammen- 
gefaßt und aufbereitet aus der Sicht des 
Software-Entwicklers. Kein reines Lehr- 
buch also, sondern in erster Linie ein 
Nachschlagewerk von bleibendem Wert. 
Ein Buch, bei dem allein die Fakten 
zählen: die Hardware des PCs, DMA- 
Controller, die mathematischen Copro- 
zessoren, Hard- und Software-Interrupts, 
Aufruf von Interrupts in BASIC, Pascal 
und C, die Funktionen des DOS, COM- 
und EXE-Programme, Zugriff auf Direc- 
tories, die EXEC-Funktionen, RAM-Spei- 
cherverwaltung des DOS, DOS-Geräte- 
treiber, Grafikkarten und ihre Program- 
mierung, TSR-Programme, EMS, Booten 
des Systems... Dazu zahlreiche Beispiele 
zur Systemprogrammierung in BASIC, 
Turbo Pascal, C und Assembler. Und sollte 
Ihnen dies allein noch keine DM 98; wert 
sein, die beiden beigelegten 5Y4”-Dis- 
ketten mit insgesamt 1 MegaByte(!) 
Source werden auch Sie überzeugen. 
PC Intern - Know-how aus erster Hand. 
Ein absolutes Muß. 


PC Intern 2.0 

Hardcover, ca. 950 Seiten 

inkl. zwei 5 %4”-Disketten, DM 98,- 
erscheint ca.12/88 


Merowingerstr. 30 - 4000 Düsseldorf - Tel. (0211) 310010 


Hiermit bestelle ich PC Intern 2.0 für DM 98, 
] per Nachnahme 
U] Verrechnungsscheck liegt bei 


NAME, VORNAME 


STRASSE 


ORT 


SPRUNG DURCH 
KNOW-HOW 


R. Kost 
Microsoft-Excel-Schulung 
Für Selbststudium und 
Gruppenunterricht. 

1988, 578 Seiten, 

inkl. Diskette 

Bestell-Nr. 90632 

ISBN 3-89090-632-X 

DM 98,- 


r 


Markt &fechnik 


Effektives _ 
Programmieren in 


Bra 


S. Baloui 

Effektives Programmie- 
ren in GW-Basic 

Eine problemorientierte 
Anleitung zum Entwickeln 
komplexer Programme. 
1987, 420 Seiten, 

inkl. Diskette 

Bestell-Nr. 90464 

ISBN 3-89090-464-5 

DM 69,- 


* Unverbindliche Preisempfehluna 


.®@ 


Markt Technik 


LTR 


PROFI-TOOLS 
QuickBASIC AD 


S. Baloui 

Profi-Tools QuickBasic/PC 
Version 4.0 

Professionelle Assembler- 
und Basic-Routinen. 
Bestell-Nr. 90655 

ISBN 3-89090-655-9 

DM 98,-* 


Markt &fechnik 


Zeitschriften 
Software 


Die Norton Guides Engine 


Die Online-Programmier- 
hilfe für Profis. 
5'/a”-Diskette, 

Bestell-Nr. 55140 
3'h"-Diskette, 

Bestell-Nr. 55141 


SOFTWARE 


Markt&Technik 


MarktTechnik 


Maufa&Technik _ NN 


R. Valentin 
Schnellübersicht Works 
Schnelle Antworten auf alle 
Fragen bei der praktischen 
Arbeit. 

1988, 433 Seiten 
Bestell-Nr. 90688 

ISBN 3-89090-688-5 

DM 39,- 


Bücher 


Schulung 


Der Norton-Editor 
Der schnelle und viel 
seitige Programmediitor. 
5'/4”-Diskette, 
Bestell-Nr. 55132 
31»”-Diskette, 
Bestell-Nr. 55133 

je DM 269,-* 


SOFTWARE 


U.Schmidt 
MS-Windows- 
Kompendium (deutsch) 
Eine ausführliche 
Programmdokumentation 
mit vielen Tips. 

1988, 228 Seiten, 

inkl. zwei Disketten 
Bestell-Nr. 90558 

ISBN 3-89090-558-7 

DM 69,- 


Markt &Technik Verlag AG, Buchverlag, Hans-Pinsel-Straße 2, 8013 Haar bei München, Tel.: (089) 4613-0 


